-
Notifications
You must be signed in to change notification settings - Fork 20.1k
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
eth/downloader: move the pivot in beacon sync mode too #26453
Conversation
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.
LGTM!
This PRThis is this PR. IT has a fairly stable ingress rate for the duration of the sync. MasterAs you can see, the snap traffic comes if fits and bursts - not quite like the report in #26429 , where it's totally dead for the duration of the block downloads. The reason for this is this change in factor , which made factor check new heads less often. Because of this, there's a higher chance that factor misses a head, and thus that geth notices a And restarting the sync is similar to moving the pivot. |
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.
LGTM
In legacy (pre-merge) sync mode, headers were contiguously downloaded from the network and when no more headers were available, we checked every few seconds whether there are 64 new blocks to move the pivot. In beacon (post-merge) sync mode, we don't need to check for new skeleton headers non stop, since those re delivered one by one by the engine API. The missing code snippet from the header fetcher was to actually look at the latest head and move the pivot if it was more than 2*64-8 away. This PR adds the missing movement logic.
Fixes #26429.
In legacy (pre-merge) sync mode, headers were contiguously downloaded from the network and when no more headers were available, we checked every few seconds whether there are 64 new blocks to move the pivot.
In beacon (post-merge) sync mode, we don't need to check for new skeleton headers non stop, since those re delivered one by one by the engine API. The missing code snippet from the header fetcher was to actually look at the latest head and move the pivot if it was more than 2*64-8 away. This PR adds the missing movement logic.
The convoluted logic of pulling headers from disk if they don't exist in the skeleton chain shouldn't really be needed, but I've added it as a sanity check in case I'm missing some reasoning now. It should result in a warning anyway so we can investigate if that clause is actually triggered.