Skip to content

Conversation

@mjfh
Copy link
Contributor

@mjfh mjfh commented Oct 17, 2025

No description provided.

mjfh and others added 7 commits October 17, 2025 13:04
why
  More intuitive names for assigned error types
why
  Explicitly check for block headers or blocks to unstage queued block
  headers or blocks. Not explicitly unstaging might lead to unnecessary
  (maybe small) delays when ending the header or block sync phase.
why
  When there are more than enough peers available to fetch data
  simultaneously, only those are selected that are unknown or
  have shown higher throughput when fetching.
why
  There is no need to zombify sync peers unless they deliver ostensibly
  bogus data.

  With zero response, only throughput statistics will be affected if a
  peer responses in time. Low throughput will leave a peer available
  but ignored if there are other peers with higher throughput unless
  all peers can run parallel.
why
  When most higher throughputs are equal then case all ranks must
  be the topmost rank (an not the least.) Otherwise one might have
  delays until the situation is resolved.
why
  Previously, syncer peers that did not deliver and ran in a timeout
  were not marked degraded (for ranking) but rather the error count
  increased.

  As a consequence, these peers did not lose with ranking. This led
  these peers linger on and tried again until the error count threshold
  was reached.
@mjfh mjfh merged commit fe162f0 into master Oct 18, 2025
18 checks passed
@mjfh mjfh deleted the Beacon-sync-update-peer-connection-mgmnt branch October 18, 2025 10:55
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.

1 participant