-
Notifications
You must be signed in to change notification settings - Fork 214
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
[Merged by Bors] - sync: prioritize peers with higher success rate and low latency #5143
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #5143 +/- ##
==========================================
+ Coverage 0 77.7% +77.7%
==========================================
Files 0 259 +259
Lines 0 30495 +30495
==========================================
+ Hits 0 23704 +23704
- Misses 0 5299 +5299
- Partials 0 1492 +1492
|
|
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.
Did you benchmark the SelectBest()
method? I'm not sure how often it is called and what's the expected total number of peers, but it takes around 3ms to find 10 best peers from a set of 50.
bors try |
tryBuild failed: |
@poszu i added benchmark. below is SelectBest(10) from 10000 total. how did you get 3 ms?
|
bors merge |
closes: #5127 #5036 peers that are overwhelmed or generally will not be used for requests. there are two criteria used to select good peer: - request success rate . success rates within 0.1 (10%) of each other are treated as equal, and in such case we will use latency - latency. hs/1 protocol used to track latency, as it is the most used protocol and objects served in this protocol are of the same size with several exceptions (active sets, list of malfeasence proofs). related: #4977 limits number of peers to request data for atxs. previously we were requesting data from all peers atleast once. synced data 2 times in 90m, previous attempt on my computer was 1 week ago and took 12h
Build failed: |
bors merge |
bors cancel |
Canceled. |
b0c679d
to
dcca7de
Compare
bors merge |
closes: #5127 #5036 peers that are overwhelmed or generally will not be used for requests. there are two criteria used to select good peer: - request success rate . success rates within 0.1 (10%) of each other are treated as equal, and in such case we will use latency - latency. hs/1 protocol used to track latency, as it is the most used protocol and objects served in this protocol are of the same size with several exceptions (active sets, list of malfeasence proofs). related: #4977 limits number of peers to request data for atxs. previously we were requesting data from all peers atleast once. synced data 2 times in 90m, previous attempt on my computer was 1 week ago and took 12h
Pull request successfully merged into develop. Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page.
|
I'm sorry, my bad - I can't do the math 🤦 it was 3µs. |
…emeshos#5143) closes: spacemeshos#5127 spacemeshos#5036 peers that are overwhelmed or generally will not be used for requests. there are two criteria used to select good peer: - request success rate . success rates within 0.1 (10%) of each other are treated as equal, and in such case we will use latency - latency. hs/1 protocol used to track latency, as it is the most used protocol and objects served in this protocol are of the same size with several exceptions (active sets, list of malfeasence proofs). related: spacemeshos#4977 limits number of peers to request data for atxs. previously we were requesting data from all peers atleast once. synced data 2 times in 90m, previous attempt on my computer was 1 week ago and took 12h
closes: #5127 #5036
peers that are overwhelmed or generally will not be used for requests. there are two criteria used to select good peer:
related: #4977
limits number of peers to request data for atxs. previously we were requesting data from all peers atleast once.
synced data 2 times in 90m, previous attempt on my computer was 1 week ago and took 12h