-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
Post startup stalling #29281
Comments
Discussed this briefly with @mzumsande. The stalling detection logic is ineffective here, because that only triggers when the 1024-block wide download window cannot move, and as you're less than 1024 blocks behind, the window is already as far as it can go. We should probably have a separate criterion for stalling detection in this case. |
Another question is how to deal with it after having a separate detection criterion. |
I'm working on a solution for this, will hopefully open a PR in the next couple of days. |
see #29664 |
Noticed this on a node recently. Basically startup, sync two blocks, but then stall for 15 minutes, until we timed out a peer (in this case a blocks-only peer). @mzumsande mentioned this is because we were too close to tip, for the stalling logic to kick in, but also not close enough for the parallel download logic to kick in. I'm wondering if we should adjust the thresholds for either, to try and make this less likely to occur. It's possible this is also the same issue being seen here: #12291 (comment).
The text was updated successfully, but these errors were encountered: