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

Peer scorer: weighted sorting, requests capping, stale peers handling. #6928

Merged
merged 12 commits into from
Aug 9, 2020

Conversation

farazdagi
Copy link
Contributor

@farazdagi farazdagi commented Aug 7, 2020

What type of PR is this?

Feature

What does this PR do? Why is it needed?

  • Extends peer scorer for Peer scoring: init sync #6709 (that's this PR is prerequisite for the 6709):
    • Adds weighted sorter routine (where peers are returned in sorted order but probabilistically, high scorers have higher chances to be high in list). This makes sure that we favour high scorers, but still allow other peers to participate.
    • Better handling of new peers: if peer hasn't been used, its given a maximum score.
    • Better handling of stale peers: if peer has been used, but failed to provide many blocks, its score is low, and there are probabilistically little chance of it being picked. At DefaultBlockProviderStalePeerRefreshInterval interval such peers will be given a score boost, and system will recheck if their weak performance was characteristic or just a bad luck.
    • Capping the maximum blocks logged: once peer is providing a certain rate of incoming batches, no need to to increase processed blocks counter -- we already see that it is a good peer. So, max processed blocks counters are capped, and every peer reaching that cap, is max scoring, good peer.
    • More simple and fine-tuned decaying is possible: to make sure that churns are frequent, one can tune decay interval and number of batches to be thrown away (simple yet efficient).

E.g.: Set decay period to 30 seconds, and decay to 5 (out of 20 max batches -- the default cap). Every decay period, 5 batches are subtracted. This puts pressure on peer that wants to come up with a high score: it must fetch more than 5 batches per decay period to increase its score.

Which issues(s) does this PR fix?

Part of #6622

Other notes for review

  • In addition to extensive unit tests, this code has been tested on Altona and Medalla.
  • It is "safe" to merge this PR, breaking changes will be in a separate PR: Peer scoring: init sync #6709

@farazdagi farazdagi self-assigned this Aug 7, 2020
@farazdagi farazdagi changed the title Peer scorer: weighted sorting, requests capping. Peer scorer: weighted sorting, requests capping, stale peers handling. Aug 7, 2020
@farazdagi farazdagi requested a review from nisdas August 7, 2020 16:29
@farazdagi farazdagi marked this pull request as ready for review August 7, 2020 16:34
@farazdagi farazdagi requested a review from a team as a code owner August 7, 2020 16:34
@farazdagi farazdagi added OK to merge Ready For Review A pull request ready for code review labels Aug 7, 2020
@codecov
Copy link

codecov bot commented Aug 7, 2020

Codecov Report

Merging #6928 into master will increase coverage by 1.85%.
The diff coverage is 73.41%.

@@            Coverage Diff             @@
##           master    #6928      +/-   ##
==========================================
+ Coverage   60.07%   61.92%   +1.85%     
==========================================
  Files         323      389      +66     
  Lines       27422    30433    +3011     
==========================================
+ Hits        16473    18845    +2372     
- Misses       8733     8920     +187     
- Partials     2216     2668     +452     

@prylabs-bulldozer prylabs-bulldozer bot merged commit b241faf into master Aug 9, 2020
@farazdagi farazdagi deleted the peer-scorer-weighted-sorter branch August 9, 2020 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready For Review A pull request ready for code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants