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
Full rework of the BlockFetch logic for bulk sync mode (#1179)
Integrates a new implementation of the BulkSync mode, where blocks are
downloaded from alternative peers as soon as the node has no more blocks
to validate while there are longstanding requests in flight.
This PR depends on the new implementation of the BulkSync mode
(IntersectMBO/ouroboros-network#4919).
`cabal.project` is made to point to a back-port of the BulkSync
implementation on `ouroboros-network-0.16.1.1`.
### CSJ Changes
CSJ is involved because the new BulkSync mode requires to change the
dynamo if it is also serving blocks, and it is not sending them promptly
enough. The dynamo choice has an influence in the blocks that are chosen
to be downloaded by BlockFetch.
For this sake, b93c379 gives the ability to order the ChainSync clients,
so the dynamo role can be rotated among them whenever BlockFetch
requests it.
b1c0bf8 provides the implementation of the rotation operation.
### BlockFetch tests
c4bfa37 allows to specify in tests in which order to start the peers,
which has an effect on what peer is chosen as initial dynamo.
c594c09 in turn adds a new BlockFetch test to show that syncing isn't
slowed down by peers that don't send blocks.
### Integration of BlockFetch changes
The collection of ChainSync client handles now needs to be passed
between BlockFetch and ChainSync so dynamo rotations can be requested by
BlockFetch.
The parameter `bfcMaxConcurrencyBulkSync` has been removed since blocks
are not coordinated to be downloaded concurrently.
These changes are in 6926278.
### ChainSel changes
Now BlockFetch requires the ability to detect if ChainSel has run out of
blocks to validate. This motivates 73187ba, which implements a mechanism
to measure if ChainSel is waiting for more blocks (starves), and
determines for how long.
The above change is not sufficient to measure starvation. The queue to
send blocks for validation used to allow only for one block to sit in
the queue. This would interfere with the ability to measure starvation
since BlockFetch would block waiting for the queue to become empty, and
the queue would quickly become empty after taking just 1 block. For
download delays to be amortized, a larger queue capacity was needed.
This is the reason why a fix similar to
IntersectMBO/ouroboros-network#2721 is part of
0d3fc28.
### Miscellaneous fixes
#### CSJ jump size adjustment
When syncing from mainnet, we discovered that CSJ wouldn't sync the
blocks from the Byron era. This was because the jump size was set to the
length of the genesis window of the Shelley era, which is much larger
than Byron's. When the jump size is larger than the genesis window, the
dynamo will block on the forecast horizon before offering a jump that
allows the chain selection to advance. In this case, CSJ and chain
selection will deadlock.
For this reason we set the default jump size to the size of Byron's
genesis window in 028883a. This didn't show an impact on syncing time in
our measures. Future work (as part of deploying Genesis) might involve
allowing the jump size to vary between different eras.
#### GDD rate limit
GDD evaluation showed an overhead of 10% if run after every header
arrives via ChainSync. Therefore, in b7fa122 we limited how often it
could run, so multiple header arrivals could be handled by a single GDD
evaluation.
#### Candidate fragment comparison in the ChainSync client
We stumbled upon a test case where the candidate fragments of the dynamo
and an objector were no longer than the current selection (both peers
were adversarial). This was problematic because BlockFetch would refuse
to download blocks from these candidates, and ChainSync in turn would
wait for the selection to advance in order to download more headers.
The fix in e27a73c is to have the ChainSync client disconnect a peer
which is about to block on the forecast horizon if its candidate isn't
better than the selection.
#### Candidate fragment truncations
At the moment, it is possible for a candidate fragment to be truncated
by CSJ when a jumper jumps to a point that is not younger than the tip
of its current candidate fragment. We encountered tests where the jump
point could be so old that it would fall behind the immutable tip, and
GDD would ignore the peer when computing the Limit on Eagerness. This in
turn would cause the selection to advance into potentially adversarial
chains.
The fix in dc5f6f7 is to have GDD never drop candidates. When the
candidate does not intersect the current selection, the LoE is not
advanced. This is a situation guaranteed to be unblocked by the
ChainSync client since it will either disconnect the peer or bring the
candidate to intersect with the current selection.
0 commit comments