[forge] Latency baseline with 1 slow validator at 4k TPS by danielxiangzl · Pull Request #19330 · aptos-labs/aptos-core

danielxiangzl · 2026-04-04T01:56:31Z

Forge harness for measuring commit-latency baseline against leader-reputation experiments.

Setup

7 validators, 0 fullnodes, ConstTps 4000, 20-minute steady-state window
24-hour epoch (no reconfigurations during the test)
Faulty validator simulation: last validator (by ordered index) delays its proposal by 1s on every 10th round (~10% of its rounds), guaranteeing round timeout

Use

Baseline reference for #19341 (latency-weighted leader-reputation experiment).

⚠ Prototype/experiment code — not for merge to main.

Forge harness for measuring commit-latency baseline against leader- reputation experiments. Self-contained: - realistic_env_max_load: ConstTps 4000 with 7 validators, 0 fullnodes - 24-hour epoch_duration_secs (no epoch changes during the test) - 20-min effective duration via with_duration_override(1200) - Last validator (by ordered index) simulates a slow proposer: 1s proposal delay every 10th round, guaranteeing round timeout Adds the duration_override plumbing to ForgeConfig/runner so individual tests can override the CLI duration. No P90 latency or multi-region changes; pure baseline for A/B against latency-weighted leader-rep. Prototype/experiment code -- not for merge to main. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

github-actions · 2026-04-27T21:32:47Z

✅ Forge suite `realistic_env_max_load` success on `9e0d4e5589a2d36080e606ee63e7b10ed004b6b1`

two traffics test: inner traffic : committed: 3999.99 txn/s, latency: 443.56 ms, (p50: 300 ms, p70: 300, p90: 900 ms, p99: 1500 ms), latency samples: 74480
two traffics test : committed: 100.00 txn/s, latency: 330.47 ms, (p50: 200 ms, p70: 300, p90: 500 ms, p99: 1200 ms), latency samples: 4280
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 0.217, avg: 0.169", "ConsensusProposalToOrdered: max: 0.084, avg: 0.082", "ConsensusOrderedToCommit: max: 0.021, avg: 0.017", "ConsensusProposalToCommit: max: 0.105, avg: 0.099"]
Max non-epoch-change gap was: 1 rounds at version 1258 (avg 0.00) [limit 4], 1.24s no progress at version 1747786 (avg 0.04s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.00s no progress at version 0 (avg 0.00s) [limit 16].
Test Ok

…onfig Continuous, per-validator weight scaling for leader reputation that prefers validators with lower historical commit-to-commit interval as proposers. Gated behind a new on-chain config variant so all validators deterministically agree on whether to enable it (no rollout fork). Heuristic (LatencyWeightedHeuristic): - compute_round_times splits successful pair intervals 50/50 between newer/older proposer; attributes timeout-spanning gaps in full to the failed proposer(s) via failed_proposer_indices. - get_weights aggregates per-validator round-time observations using *mean* (not median, which discarded the failure tail). Scales by (max_mean / val_mean)^multiplier with a per-validator fallback below MIN_OBSERVATIONS=2, a MAX_LATENCY_RATIO=10x ceiling, and degenerate guards (empty / zero max_mean -> base weights). On-chain gate: - New ProposerAndVoterV3(ProposerAndVoterConfigV3) variant with use_latency_weighted: bool and latency_weight_multiplier_milli: u32 (BCS-friendly milli-units, 1000 = 1.0x). Version-agnostic proposer_and_voter_params() accessor returns the toggle for V1/V2 (false) and V3. Wiring: epoch_manager reads via proposer_and_voter_params; dag/bootstrap handles V3 by using its base config; smoke-test match arms cover V3. Forge config sets use_latency_weighted=true with default proposer_window_num_validators_multiplier=10 -- the window-bump experiment lives in a companion PR for A/B comparison. Tests: 7 new unit tests for the heuristic. All 18 leader-reputation lib tests pass. Stacks on baseline #19330; companion to the window-bump experiment in a separate PR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ht + larger window Tunes the existing ProposerAndVoter binary classifier on three axes so it reliably bans a slow validator instead of leaving it oscillating at the threshold boundary: - failure_threshold_percent: 10 -> 5 V6's injected real failure rate is 10%, exactly at the default threshold. Sampling noise pushed it above only ~26-38% of windows. Lowering the threshold to 5 makes V6's 10% clearly exceed it under any window size. - failed_weight: 1 -> 0 When a validator IS classified failed, it currently keeps a tiny weight (1 vs active 1000), still leaking ~1/N share. Setting to 0 fully excludes. - proposer_window_num_validators_multiplier: 10 -> 50 Larger observation window reduces variance in the failure-rate estimate, so classification flips less and is more decisive when it does. No heuristic changes. Stacks on baseline #19330. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

danielxiangzl force-pushed the daniel/latency-baseline-by-skip branch from d0bbcfd to ea3ef6f Compare April 4, 2026 01:58

danielxiangzl added the CICD:run-forge-e2e-perf Run the e2e perf forge only label Apr 4, 2026