-
Notifications
You must be signed in to change notification settings - Fork 87
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 diffusion pipelining #3688
Conversation
63b8012
to
4cc618f
Compare
Esgen thinks the CI failure on 4cc618f is spurious. He's going to write an explanation here soon. I'm going to rerun Hydra right now -- this comment is just a placemarker since the CI failure he will reference is likely to no longer be apparent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GH Windows failure is unrelated (see #3678), (EDIT: now fixed) so LGTM from my side 🎉
4cc618f
to
bb78cfc
Compare
Status update: the first benchmarking run showed that we're not actually pipelining. We believe we've fixed it and are now awaiting a second benchmarking run. We'll be pushing those commits here soon. |
9da1886
to
34086e3
Compare
An (optional) idea: split 4fa8cda into a commit that just undoes/reverts changes and a second commit that adds the new behavior. |
Minor: 4fa8cda has some extra layer of |
I can do that if it is helpful for reviewing 👍. In the end, we want to squash 4fa8cda into aa43e5d, so it won't matter there.
Ah yes, that happend while I swapped the two commits (such that the squashing becomes trivial), will change that (EDIT: done). |
8dae7a9
to
a50c3f5
Compare
d5af480
to
60f0771
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rebased onto origin/master
and did one last pass. I found a tvar with a Maybe
and a stale comment.
@amesgen would you fix that (preferably squash the fix) and then merge?
ouroboros-consensus/src/Ouroboros/Consensus/Storage/ChainDB/Impl/Types.hs
Outdated
Show resolved
Hide resolved
60f0771
to
20df233
Compare
20df233
to
fef1c47
Compare
…l duplex connections Also, bump the default max version to V_8, to include pipelining.
We want to store the `SelectView` of the last invalid tentative header in an `StrictTVar`.
Disconnect if either the block itself is invalid or one of the blocks on its prefix is.
The idea is to change the instruction-emitting parts of the `Follower` abstraction to be aware of the tentative chain. Concretely, we now use `getCurrentChainByType` instead of `readTVar cdbChain` in two occasions: 1. When we are rolling forward from an in-memory point, which is the most relevant case for pipelining (as pipelining is only relevant when the follower is at the tip of our chain). This change is crucial: If we erroneously would use the selected chain in a tentative follower, rolling forward from the tentative point would result in us jumping back to the immutable DB as the tentative header is never part of the selected chain, which would then trigger an error as the tentative header is never in the immutable DB. 2. When rolling forward from a point in the immutable DB, when we are about to switch to the in-memory fragment. In most cases, the choice will be irrelevant here, except for this rare scenario (data loss in the VolDB): `cdbChain` could be empty, and the tentative header could be set, in which case we can roll forward tentative followers which are at the tip of the immutable DB. We leave follower forwarding (triggered via `MsgFindInteresct`) untouched as pipelining is only concerned with up-to-date peers.
fef1c47
to
e140bb4
Compare
bors merge |
Thank @amesgen for preparing this one with me! The benchmarking results show improvement, so we're good to merge. We still have some room for improvement in the benchmarks and new tests, but this PR is a solid first step. |
3688: Block diffusion pipelining r=nfrisby a=nfrisby This PR adds block diffusion pipelining, primarily by finally introducing the long-existing concept of _the tentative chain_ into the code. Main changes: - add the tentative chain header to the ChainDB state. - have the `Follower`s for the Node-To-Node ChainSync server follow the tentative chain instead of only the selected chain, thus sending the tentative header before the underlying block has been validated - this now means some honest nodes will send us an invalid block, when the block is tentative, so we adjust ChainSync and BlockFetch clients to allow that in limited number of scenarios necessary for the common pipelining scenarios Co-authored-by: Nicolas Frisby <[email protected]> Co-authored-by: Alexander Esgen <[email protected]>
This PR adds block diffusion pipelining, primarily by finally introducing the long-existing concept of the tentative chain into the code.
Main changes:
add the tentative chain header to the ChainDB state.
have the
Follower
s for the Node-To-Node ChainSync server follow the tentative chain instead of only the selected chain, thus sending the tentative header before the underlying block has been validatedthis now means some honest nodes will send us an invalid block, when the block is tentative, so we adjust ChainSync and BlockFetch clients to allow that in limited number of scenarios necessary for the common pipelining scenarios