You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update error register names
why
More intuitive names for assigned error types
* Cosmetics, update logging
* Update `worker` module (with basic tasks managed by scheduler)
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.
* Classify syncer peers and select `faster` ones for downloading
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.
* Relax fetch response timeouts and error threshold
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.
* Fix fringe case when all higher throughput measurements are equal
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.
* Degrade ranks of useless peers as well as increasing their error count
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.
---------
Co-authored-by: jordan <jordan@curd>
0 commit comments