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

Prefer faster peers, but if all peers are slow, still connect to them #4226

Closed
teor2345 opened this issue Apr 28, 2022 · 1 comment
Closed
Labels
C-bug Category: This is a bug I-slow Problems with performance or responsiveness S-needs-design Status: Needs a design decision

Comments

@teor2345
Copy link
Contributor

teor2345 commented Apr 28, 2022

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:

  • prefer faster peers,
  • but remove the fixed peer handshake timeout, so that Zebra still works on slow networks.

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:

  • if we're at the connection limit, reduce the peer timeout by 1 second
  • if we have less than the initial connection target, double the peer timeout

We only want to count connections that have successful handshakes. We'd need to limit the range of the timeout to 1..=request timeout.

@teor2345 teor2345 added C-bug Category: This is a bug S-needs-triage Status: A bug report needs triage P-Low ❄️ I-slow Problems with performance or responsiveness labels Apr 28, 2022
@teor2345 teor2345 added the S-needs-design Status: Needs a design decision label Jun 2, 2022
@teor2345
Copy link
Contributor Author

This seems to be fine for now

@teor2345 teor2345 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 25, 2022
@mpguerra mpguerra removed the S-needs-triage Status: A bug report needs triage label Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug I-slow Problems with performance or responsiveness S-needs-design Status: Needs a design decision
Projects
None yet
Development

No branches or pull requests

2 participants