add timeboost troubleshooting guide #2113
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
||
| ## How response times work | ||
|
|
||
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced. For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is always (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. |
There was a problem hiding this comment.
This paragraph seems a bit confusing, since it starts saying that the transaction arrives at t=0ms but later say that it takes time_to_arrive to arrive.
I have some extra comments in general about the sequencer behavior explained here, that I'll share on Slack.
There was a problem hiding this comment.
How does this sound?
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced. For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is always (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. | |
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced, plus some time for the message to get through the network (`time_to_arrive`). For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is at least (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. |
There was a problem hiding this comment.
The paragraph is still confusing, at the beginning it says that the transaction arrives at t=0ms (if a transaction arrives at the Sequencer at t=0ms) but later says that it takes time_to_arrive to arrive (where time_to_arrive is the time...) 😅
Maybe it would be clearer if we say something like "If transaction is sent at t=0ms, and the block is produced at t=250ms, the expected response time is 250ms - time_to_arrive, where time_to_arrive is ..."
wdyt?
There was a problem hiding this comment.
Oh I see what you're saying, apologies. How's this? Also I think its always going to be 250ms plus time_to_arrive right?
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced. For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is always (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. | |
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced. For example, irrespective of the type of transaction (express lane or normal), if a transaction is sent to the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is at least `time_to_arrive` + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. |
There was a problem hiding this comment.
Ahh, that's less confusing, yeah. But I think the timing is still a bit off. If I send my transaction at t=0ms, and the block is produced at t=250ms, it will be confirmed at t=250ms if time_to_arrive is less than 250ms.
For example, say that I send at t=0ms, and time_to_arrive is 50ms. The transaction will make it to the next block at the t=250ms mark, but the current formula suggests that the expected response time will be 50+250ms = 300ms.
If time_to_arrive is more than 250ms, then it will make it to the next block. Always assuming that the block is not filled up before.
There was a problem hiding this comment.
Sounds good - will make a change.
There was a problem hiding this comment.
Thanks @TucksonDev for your review! How do the changes look to you now?
|
|
||
| ## How response times work | ||
|
|
||
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced. For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is always (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. |
There was a problem hiding this comment.
How does this sound?
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced. For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is always (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. | |
| The response for a <a data-quicklook-from="transaction">Transaction</a> submission is returned only once the block containing the transaction is produced, plus some time for the message to get through the network (`time_to_arrive`). For example, irrespective of the type of transaction (express lane or normal), if a transaction arrives at the <a data-quicklook-from="sequencer">Sequencer</a> at `t=0ms` and the block is produced at `t=250ms`, then the expected response time is at least (`time_to_arrive`) + 250ms, where `time_to_arrive` is the time it took for the transaction to be received by the sequencer. |
Co-authored-by: José FP <[email protected]>
Co-authored-by: José FP <[email protected]>
this pull request adds a troubleshooting guide and best practice recommendations for users of Timeboost following some testing with a few teams trying Timeboost out.
I'd really like to have a separate Timeboost section since we now have docs on: how to use timeboost, troubleshoot timeboost, and its conceptual design. We will have docs on decentralized timeboost eventually as well.