Skip to content
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

IF: net_plugin lib<->head catchup transistion change #1546

Closed
Tracked by #1508
heifner opened this issue Aug 22, 2023 · 1 comment · Fixed by #1619
Closed
Tracked by #1508

IF: net_plugin lib<->head catchup transistion change #1546

heifner opened this issue Aug 22, 2023 · 1 comment · Fixed by #1619
Assignees

Comments

@heifner
Copy link
Member

heifner commented Aug 22, 2023

When lib is much closer to head, it will be very likely for a node to find its head is less than lib and think it needs to sync from a peer when in reality it is only a bit behind. Need a better heuristic for when to switch from in_sync<->head<->lib catchup modes.

This might be as simple as a hard-coded delta from peer head before assuming it is syncing (or should sync), but will require some testing.

@heifner
Copy link
Member Author

heifner commented Aug 26, 2023

  • sync_manager::recv_handshakerecv_handshake - head < msg.lib is more likely to be true. The inverse is also more likely to be true. Both conditions sync 1 & sync 2 need to not trigger lib sync unless there is a distance between head<->lib of (latency + sync_diff_range). Where sync_diff_range could be hard-coded. But I believe setting it to half of p2p-keepalive-interval-ms (default 10s) is a better option. p2p-keepalive-interval-ms makes sense as a value to tie it to because this corresponds to how long you wait before pinging a node if you have not heard from it. The default would be 5 seconds (10 blocks).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants