Sync gaps fix #4090
Sync gaps fix #4090
Conversation
| @@ -385,6 +391,47 @@ proc getLastNonEmptySlot*[T](sr: SyncResult[T]): Slot {.inline.} = | |||
| else: | |||
| sr.data[^1][].slot | |||
|
|
|||
| proc processGap[T](sq: SyncQueue[T], sr: SyncResult[T]) = | |||
There was a problem hiding this comment.
Does this need a check for sq.kind == SyncQueueKind.Forward?
| # Every empty response increases penalty by 25%, but not more than 200%. | ||
| let | ||
| emptyCount = gap.item.getStats(SyncResponseKind.Empty) | ||
| goodCount = gap.item.getStats(SyncResponseKind.Good) | ||
|
|
||
| if emptyCount <= goodCount: | ||
| gap.item.updateScore(score) | ||
| else: | ||
| let | ||
| weight = int(min(emptyCount - goodCount, 8'u64)) | ||
| newScore = score + score * weight div 4 | ||
| gap.item.updateScore(newScore) | ||
| debug "Peer received gap penalty", peer = gap.item, | ||
| penalty = newScore |
There was a problem hiding this comment.
Not sure how well it works with a simpler logic of just applying gap.item.updateScore(score) in any case. Eventually, peers should still be dropped without the extra scaling (after 10x PeerScoreNoBlocks in a row, a peer is considered useless and disconnected without scaling).
|
@cheatfate, can you file a separate issue for the fact that some of the fleet servers haven't backfilled all blocks? I guess it should be possible to confirm this also through the REST API or through direct database examination. The issue should indicate the affected hosts and service names (e.g. beacon-node-testing vs beacon-node-unstable, etc). I'm also looking forward to merge this PR for the upcoming release, but it needs to be rebased at the moment. |
cheatfate
force-pushed
the
sync-gaps-fix
branch
from
2b3bfd6
to
56930cf
Compare
No description provided.