search

EvernodeXRPL / evernode-sdk

Evernode SDK
Other
43 stars 7 forks source link

roundtime #79

Closed shortthefomo closed 1 year ago

shortthefomo commented 1 year ago

No where in the documentation does it define limits on the round times. Other than it has to be in milliseconds.

What is the upper limit of a round time? Could i have a round that lasts a hour/day/month/year?

chalith commented 1 year ago

Yes, There's an upper limit. It's in the config reference documentation

image

ravinsp commented 1 year ago

@lathanbritz This is an arbitrary limit we have placed. Do you have any usecases that can potentially have very long roundtimes?

wojake commented 1 year ago

I just don't think there should be a limit honestly, what could go wrong?

shortthefomo commented 1 year ago

If you are simply after renting the compute from the cluster(s) the longer this close time the better in some circumstances. Scott says the best way to rent simply the compute is a cluster size of 1. I've not played with it yet i was just after finding the bounds at this point....

But extending the round times complicates other parts of the code I think like passing messages to and from clients. As typically this is done on the close. So id like to build some scratch pad code and see what the hurdles are there.

wojake commented 1 year ago

I forgot to mention that the value of the roundTime field does not determine how long you could compute / stay on a particular ledger doing X, Y & Z. Your instances could be doing 100 NPL rounds in a 10 minute window and still be on the same ledger.

ravinsp commented 1 year ago

@lathanbritz If you goal is to simply fire up a long running application and keep it running as long as you want, you can even do that now regardless of the roundtime configuration. Roundtime does not "kill" the application. Roundtime is simply the "minimum" duration between two consensus rounds. If the contract application keeps running for a long time, next consensus round will not start until the app exits. Basically the app will block the consensus.

@wojake also suggested elsewhere to introduce a timer to "force kill" the application. We will add this feature too in the future. When that feature is introduced, you can use it kill any "stuck" contract after a timeout or specify 0 to let it run indefinitely (which is the current behavior).

shortthefomo commented 1 year ago

@ravinsp im confused now. Is this a recent change with the "Roundtime does not "kill" the application" as this is what i had observed when l was looking at putting the graph in there.

im a little lost now as to the life cycles of the different parts involved here.

round time, execution time, consensus round... going to need this explained better as we go.

ravinsp commented 1 year ago

@lathanbritz Probably my English made it confusing. No, nothing in this area was changed recently.

  1. Roundtime specifies the time window allocated to a consensus round. Consensus round includes exchanging the user input/output/state information between the nodes, closing a ledger with the consensed information, and then finally executing the contract with the consensed information.

  2. You need to tune the roundtime according to your needs considering the network communication delays in exchanging the information between nodes and "normal" execution time of your contract. Ideally, all the activities in [1] should be able to complete within the roundtime.

  3. To ensure smooth forward progress of your cluster, the contract is supposed to process information and exit before the total roundtime is over for the current consensus round. This ensures consensus rounds happen at regular time windows and enables distribution of outputs to users at regular intervals.

  4. However, the contract can choose to keep running for a long time, thereby delaying the end of the current consensus round. Obviously this will push back the start of the next consensus round.

  5. In a nodejs contract, the application will automatically exit if there is nothing more to process or you haven't told nodejs to wait for a timeout (this is how nodejs works). Maybe this is why you thought your application is getting "killed"?

  6. If you keep the contract running for a long time, this will halt the forward progress of the cluster, and for users who are expecting "outputs" it will look like the application is stuck.

Hope this helps.

shortthefomo commented 1 year ago

your point 5 makes sense now as to what i was experiencing there.

certainly does thank you!