Prefer faster peers, but if all peers are slow, still connect to them #4226
Labels
C-bug
Category: This is a bug
I-slow
Problems with performance or responsiveness
S-needs-design
Status: Needs a design decision
Motivation
In PR #4212, we reduced the peer handshake timeout from 4 to 3 seconds, to speed up full sync. But this could cause connection issues on slower networks.
Instead, we want to:
We don't need to do this until it actually becomes a problem for users.
Alternative Designs
Disconnect Slow Peers
Related Work
We might also want to prefer faster peers to slower peers, to improve sync speeds. This could use a similar algorithm: during the initial sync, every minute, disconnect the peer with the slowest round-trip time. (1.6 - 5 times the peer set size during a 6 hour initial sync.)
Additive Increase, Multiplicative Decrease
We could use a dynamic peer connection timeout, with an additive-decrease-multiplicative-increase algorithm.
Every minute:
We only want to count connections that have successful handshakes. We'd need to limit the range of the timeout to
1..=request timeout
.The text was updated successfully, but these errors were encountered: