2de3451011
## Issue Addressed #3212 ## Proposed Changes - Introduce a new `rate_limiting_backfill_queue` - any new inbound backfill work events gets immediately sent to this FIFO queue **without any processing** - Spawn a `backfill_scheduler` routine that pops a backfill event from the FIFO queue at specified intervals (currently halfway through a slot, or at 6s after slot start for 12s slots) and sends the event to `BeaconProcessor` via a `scheduled_backfill_work_tx` channel - This channel gets polled last in the `InboundEvents`, and work event received is wrapped in a `InboundEvent::ScheduledBackfillWork` enum variant, which gets processed immediately or queued by the `BeaconProcessor` (existing logic applies from here) Diagram comparing backfill processing with / without rate-limiting: https://github.com/sigp/lighthouse/issues/3212#issuecomment-1386249922 See this comment for @paulhauner's explanation and solution: https://github.com/sigp/lighthouse/issues/3212#issuecomment-1384674956 ## Additional Info I've compared this branch (with backfill processing rate limited to to 1 and 3 batches per slot) against the latest stable version. The CPU usage during backfill sync is reduced by ~5% - 20%, more details on this page: https://hackmd.io/@jimmygchen/SJuVpJL3j The above testing is done on Goerli (as I don't currently have hardware for Mainnet), I'm guessing the differences are likely to be bigger on mainnet due to block size. ### TODOs - [x] Experiment with processing multiple batches per slot. (need to think about how to do this for different slot durations) - [x] Add option to disable rate-limiting, enabed by default. - [x] (No longer required now we're reusing the reprocessing queue) Complete the `backfill_scheduler` task when backfill sync is completed or not required |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| .gitignore | ||
| Cargo.toml | ||
| check_all_files_accessed.py | ||
| Makefile | ||
| README.md | ||
Consensus Specification Tests
This crate parses and executes the test vectors at ethereum/consensus-spec-tests.
Functionality is achieved only via the $ cargo test --features ef_tests command.
Running the Tests
Because the test vectors are very large, we do not download or run them by default. To download them, run (in this directory):
$ make
Note: this may download hundreds of MB of compressed archives from the ethereum/consensus-spec-tests, which may expand into several GB of files.
If successful, you should now have the extracted tests in ./consensus-spec-tests.
Run them with:
$ cargo test --features ef_tests
The tests won't run without the ef_tests feature enabled (this is to ensure that a top-level
cargo test --all won't fail on missing files).
Saving Space
When you download the tests, the downloaded archives will be kept in addition to the extracted files. You have several options for saving space:
- Delete the archives (
make clean-archives), and keep the extracted files. Suitable for everyday use, just don't re-runmakeor it will redownload the archives. - Delete the extracted files (
make clean-test-files), and keep the archives. Suitable for CI, or temporarily saving space. If you re-runmakeit will extract the archives rather than redownloading them. - Delete everything (
make clean). Good for updating to a new version, or if you no longer wish to run the EF tests.