chore: reduce cycle length for AAC tests #6607
Conversation
Jiloc
added
aac
|
Nope I was debating lowering it myself in my WIP PR myself. I realized in the process that we actually lockup the stx for 12 reward cycles. So as long as we don't exceed that many reward cycles, we don't have to worry about restacking/reregistering signers. |
| // Set up chainstate to start at Epoch 3.0 | ||
| // We don't really ever want the reward cycle to force a new signer set... | ||
| // so for now just set the cycle length to a high value (100) | ||
| let mut boot_plan = NakamotoBootPlan::new(test_name) | ||
| .with_pox_constants(100, 3) | ||
| .with_pox_constants(7, 1) |
There was a problem hiding this comment.
Maybe better to keep some comment here about the signer set, specifically the constraints we need to follow to avoid having to re-register signers. That way, if we need to modify this configuration in the future, we’ll have some context and a clear reference.
There was a problem hiding this comment.
We currently have a limit of 12 reward cycles (given how pox-4 is mined though we could expand this period value from 12). Also there are some janky things around making sure that nakamoto does not activate in the same reward cycle as epoch 2.5 unless there is enough space in between for epoch 2.5 to mine pox 4 and the anchor block to be selected first. i.e. epoch 2.5 needs to mine its pox 4 BEFORE the prepare phase for the nakamoto activated reward cycle.
3 participants
Description
The consensus tests currently take 20-30 seconds each to run on my machine, mostly due to the long cycle length of 100 blocks.
The new values are the lowest ones (empirically) accepted. Reducing the running of 4 consensus tests from ~1 min and 45 secs to ~2 seconds.
Only the MARF hashes currently changes from running the same tests. But I may be missing something given @jferrant comments in the code.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yamlandrpc-endpoints.mdfor v2 endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepo