Files
rippled/docker/telemetry/workload/baselines/baseline-timings.json

11 lines
3.1 KiB
JSON

{
"_note": "PLACEHOLDER -- every entry was voided, and the next telemetry-validation run reprints a fresh block to paste back (see baselines/README.md). Span entries were captured 2026-06-05 against a spanmetrics ladder whose first edge was 1ms. That ladder had no edge below 1ms at all, so for the sub-millisecond spans nearly every sample landed in bucket 0 and their quantiles are interpolation across that single edge, not latencies: span.ledger.store read p50/p95/p99 = 0.5/0.95/0.99, exactly quantile x 1ms, and span.tx.process read 0.50428/0.95813/0.99847 for the same reason. Sub-millisecond edges (floor 0.01ms) landed 2026-08-04 in 3860c93db2, so the ladder those numbers came from no longer exists. The gate is one-sided -- compare_to_baseline.py flags a regression only when current exceeds baseline -- so a stale-high baseline passes everything in silence, including a real 10x regression from 0.05ms to 0.5ms hiding under the 0.95ms entry. The 11 entries at or above 1ms (consensus.accept p50/p95/p99, consensus.ledger_close p95/p99, ledger.build p95/p99, ledger.validate p95/p99, tx.apply p95/p99) were undistorted -- but only because every edge from 1ms to 1s is byte-identical between the two ladders and all 11 happen to fall in that band, NOT because the re-cut spared everything above 1ms. It did not: it also added 2s/3s/4s/10s/30s edges above 1s, so a span whose quantiles reach the second scale is distorted just as much. Those 11 are voided with the rest anyway: a half-filled metrics object is not a placeholder, so the gate would stay half-dead with nothing to signal it. Removed span values, for reference (ms, p50/p95/p99): consensus.accept = 1.059405940594059/9.749999999999996/23.704545454545432; consensus.ledger_close = 0.5284697508896797/1.511111111111103/7.878571428571429; ledger.build = 0.7412060301507538/4.611111111111112/7.541666666666674; ledger.store = 0.5/0.95/0.9900000000000001; ledger.validate = 0.5283687943262412/1.3666666666666627/6.699999999999978; rpc.ws_message = 0.5026522773001647/0.9550393268703128/0.9952515090543261; tx.apply = 0.6330472103004292/4.203389830508474/5.083333333333319; tx.process = 0.5042801992591597/0.9581323781882418/0.998474791584883. job.* entries were removed earlier, on 2026-08-21, for the same reason on the native microsecond ladder: its first edge was 100us with 99.3% of job_queued_us samples beneath it, so job.acceptLedger.queued.p95 = 96.79us was 0.95/0.9926 x 100. That earlier note also claimed the gate then \"gates only the span metrics, which are unaffected\" -- that was wrong, for the reasons recorded above. Removed job values, for reference (us): job.acceptLedger.queued.p95=96.79, job.acceptLedger.running.p95=10562.50, job.transaction.queued.p95=478.97, job.transaction.running.p95=494.14. Both groups need recapture on a node running the re-cut ladders. captured_at, git_sha, profile and window below describe the voided run, not a live baseline.",
"captured_at": "2026-06-05T18:41:52Z",
"git_sha": "fd1c8c6060f7a15cc9e65b16f99629d9ab7ac7dc",
"metrics": {},
"placeholder": true,
"profile": "full-validation",
"schema_version": 1,
"window": "3m"
}