Skip to content

6803 - adding code for updating pivot#6818

Closed
ssonthal wants to merge 4 commits into
NethermindEth:masterfrom
ssonthal:6803_do_not_mark_peer_as_low_quality
Closed

6803 - adding code for updating pivot#6818
ssonthal wants to merge 4 commits into
NethermindEth:masterfrom
ssonthal:6803_do_not_mark_peer_as_low_quality

Conversation

@ssonthal

@ssonthal ssonthal commented Mar 9, 2024

Copy link
Copy Markdown
Contributor

Fixes #6803

Please choose one of the keywords above to refer to the issue this PR solves followed by the issue number (e.g. Fixes #000). If no issue number, remove the line. Also, remove everything marked optional that is not applicable. Remove this note after reading.

Changes

  • List the changes

Types of changes

What types of changes does your code introduce?

  • Bugfix (a non-breaking change that fixes an issue)
  • New feature (a non-breaking change that adds functionality)
  • Breaking change (a change that causes existing functionality not to work as expected)
  • Optimization
  • Refactoring
  • Documentation update
  • Build-related changes
  • Other: Description

Testing

Requires testing

  • Yes
  • No

If yes, did you write tests?

  • Yes
  • No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

  • Yes
  • No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

  • Yes
  • No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

@LukaszRozmej

Copy link
Copy Markdown
Member

I think it is too simplistic - related to the linked issue - we need to punish the peer in most cases, only if it is the only peer (or maybe 1 of a very small amount? - would need empirical testing) we want to take a different path.

@ssonthal

Copy link
Copy Markdown
Contributor Author

I think it is too simplistic - related to the linked issue - we need to punish the peer in most cases, only if it is the only peer (or maybe 1 of a very small amount? - would need empirical testing) we want to take a different path.

@LukaszRozmej , so is there a way to check if the number of peers == 1, and only then update the pivot?

@LukaszRozmej

Copy link
Copy Markdown
Member

You would have to go through SyncPeerPool, check for capabilities ect.

@ssonthal

Copy link
Copy Markdown
Contributor Author

Hi @LukaszRozmej can we use the count of the _logResult to determine if the number of connected peers is 1 ?

@LukaszRozmej

Copy link
Copy Markdown
Member

Not sure @dceleda what do you think?

@ssonthal

Copy link
Copy Markdown
Contributor Author

Hi @dceleda, could you confirm if we can use the length of the _resultLog array to determine the number of peers?

the _resultLog is defined as folllows -

private readonly LinkedList<(PeerInfo peer, AddRangeResult result)> _resultLog = new();

@asdacap

asdacap commented Mar 19, 2024

Copy link
Copy Markdown
Contributor

its also possible that the peer just drop the state as it was too old, so there could be case where the resultlog.count > 1, not to mention its almost always a rolling list so it should almost all the time be more than 1. Maybe just also check consecutive failure? As in, if there are no success for the past n request, then chances are, pivot need to be updated, not the peer need to be punished.

@ssonthal

Copy link
Copy Markdown
Contributor Author

its also possible that the peer just drop the state as it was too old, so there could be case where the resultlog.count > 1, not to mention its almost always a rolling list so it should almost all the time be more than 1. Maybe just also check consecutive failure? As in, if there are no success for the past n request, then chances are, pivot need to be updated, not the peer need to be punished.

Since resultlog count check won't work, can we check the value of peerLastFailures? If it's beyond or below a certain threshold, we can try to update the pivot.

@ssonthal

Copy link
Copy Markdown
Contributor Author

HI @LukaszRozmej/ @asdacap could you advise on the next steps for this one.

@ssonthal ssonthal deleted the 6803_do_not_mark_peer_as_low_quality branch September 10, 2024 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Do not mark peer as low quality too soon if there is only one peer connected

3 participants