Skip to content

perf(p2p): pipeline block and header requests during sync - #2162

Draft
nullPointerEnjoyer wants to merge 2 commits into
mintlayer:masterfrom
nullPointerEnjoyer:perf/header-sync-pipelining
Draft

nullPointerEnjoyer wants to merge 2 commits into
mintlayer:masterfrom
nullPointerEnjoyer:perf/header-sync-pipelining

Conversation

@nullPointerEnjoyer

Copy link
Copy Markdown
Collaborator

Summary

Keeps the peer's send stream continuous during the block download instead of stopping between batches:

  • Block-batch top-up: while blocks are in flight, the next portion of the staged headers is requested as soon as the outstanding count drops below half of max_request_blocks_count, so the peer starts serving the next batch without waiting for the current one to fully drain. Total outstanding requests stay within max_request_blocks_count, which is also the serving limit peers enforce on their side.
  • Header look-ahead window: header requests keep up to 2 × msg_header_count_limit headers staged ahead of the download, so header fetch overlaps block fetch. Requests are issued only while the window is below the target and the previous response actually staged new headers, so repeated or purely overlapping lists cannot turn into request loops (the consecutive known-full-lists backpressure is unchanged).
  • Overlap trimming: header responses received during a download are anchored at the last processed block, so they legitimately repeat in-flight/staged headers. The repeated prefix is skipped; the staged window stays a single connected chain onto a known or in-flight header (branching lists keep the window connected up to the branch point; wholesale divergences replace it, as before).
  • Known-block filtering: staged headers whose blocks arrived from another peer in the meantime are filtered out before mid-flight requests, mirroring the existing batch drain path.

Out-of-order and unsolicited block handling, stall detection, the fork download budget, and wait_for_clock_diff are unchanged.

Verification

  • cargo test -p p2p --lib: 340 passed (330 pre-existing + 10 new/extended), covering: pipelined request continuity, no duplicate/out-of-limit requests, overlap dedup without spin, window bound under divergent zero-overlap lists (capacity cap exercised at exactly the target), reorg-mid-download connectivity, known-lists grace after a download, budget deferral + retry during a download, and lockstep degradation at small request limits.
  • ./do_checks.sh (fmt / deny / vet / clippy ×2 / codecheck / wasm-docs): pass.
  • cargo test -p chainstate-test-suite: pass.

Notes

  • No consensus surface; p2p-local change against master post-perf(experimental): IBD and indexer performance improvements  #2156.
  • Measured mainnet A/B numbers: pending (existing ibd-ab harness, run D vs run C baseline 5,164 s). Expected effect is largest on high-RTT peers; will be appended when available.
  • Draft / held from merge until the 1.5.0 content set is final.

Keep the peer's send stream continuous during the block download instead
of stopping between batches: while blocks are in flight, the next portion
of the staged headers is requested as soon as the outstanding count drops
below half the request limit, and header requests keep a look-ahead window
of up to twice the header list limit staged ahead of the download.

Header responses received during the download are anchored at the last
processed block, so they legitimately repeat headers that are still in
flight or staged; the repeated prefix is skipped before the remaining
headers are staged, keeping the look-ahead a single connected chain onto
a known or in-flight header. Diverging lists replace the staged window,
branching lists keep the window connected up to the branch point.

Staged headers that turned out to be already known are filtered out
before the mid-flight request, mirroring the batch drain path. The total
number of outstanding requested blocks stays within
max_request_blocks_count, which is also the serving limit peers enforce
on their side.
Pin the pipelining behavior at small protocol limits: the peer's block
requests stay within the request limit and free of duplicates while in
flight, batch boundaries overlap, repeated and purely overlapping header
lists produce no requests, the staged look-ahead is bounded by twice the
header list limit, a diverging header list keeps the window connected,
the consecutive known-lists grace still applies after a download, the
fork download budget defers lists during a download until its retry, and
small request limits degrade to lockstep batching as before. The header
list request test now expects the look-ahead top-up request that is sent
while the first batch is being downloaded.
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