-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block propagation delay under load #525
Comments
I marked this as an enhancement, but I do think it should be back-ported to 3.1 & 3.2. |
This currently prevents eosnetworkfoundation/product#127 from propagating a block as quickly as it could without this change. If 127 is implemented so that it does not need the main thread for block header validation then the block can be propagated quickly without this change. However, even with 127 implemented so it does not need the main thread, this solution is still needed because you do want to start applying the state changes from the incoming block as soon as possible. For a speculative block you want to abort it as soon as you have a new block to apply. |
Example where this is needed:
It is very likely that block |
…ative mode. Use deadline when in production mode.
…uld restart block because speculative block may have been interrupted.
…uld restart block because speculative block may have been interrupted.
[3.1] Interrupt speculative start_block when a block is received
…merge [3.1 -> 3.2] Interrupt speculative start_block when a block is received
…-merge [3.2 -> main] Interrupt speculative start_block when a block is received
During
start_block
a deadline is set so that trx processing does not exceed the configured block production window according toproduce-time-offset-us
andcpu-effort-percent
. Pending transactions are processed in a tight loop on the main thread until all pending are processed or the deadline is hit.For a production block, if a block comes in during the block production window it is dropped.
For a speculative block, the incoming block is not processed until the main thread is released for processing the next task. Currently this means that the incoming block is not processed until after the completion of
start_block
. This can delay the incoming block processing by as much as 500ms.Block propagation can be improved during high load by exiting speculative block
start_block
when a block comes into the node so that it can be processed immediately after the execution of the current trx.The text was updated successfully, but these errors were encountered: