Files
rippled/docker/telemetry/workload/baselines/baseline-timings.json
Pratik Mankawde a734da8b33 test(telemetry): recapture the baseline and stop gating what variance dominates
Refreshes baselines/baseline-timings.json from run 32964262700 at 8418d474a7,
byte-identical to the CI artifact. The previous baseline was captured at
6a82fc6f37, before the path-finding load was removed from the workload, so it
described a load shape the harness no longer runs.

Every absolute bound is re-derived, because the rule is hi_next minus baseline
and the baselines moved.

Three more keys stop being gated: span.tx.apply.p50, span.ledger.build.p50 and
span.consensus.ledger_close.p50. This is the rule the previous commit recorded
being applied, not a new exception -- a key is gateable only when its
run-to-run spread fits inside its bound.

The evidence is span.tx.apply.p50, which read 0.7917 ms in the old baseline and
0.00597 ms in this one. That is a 132x move between two runs of the SAME
workload. The old value happened to land mid-distribution, so hi_next minus
baseline gave a 4.21 ms bound that absorbed the spread; the new value lands in
the ladder's first bucket, so the same rule gives 0.0440 ms and cannot survive
one. Whether the gate functioned was decided by where in the distribution the
captured run happened to fall, which is not a threshold in need of tuning.
Measured spreads across four runs agree: 364x, 25.3x and 5.9x respectively.

All five excluded keys share one shape -- a baseline landing in the ladder's
low buckets, where the derived bound is tiny, together with large run-to-run
spread. Single-run baselines cannot support them; a multi-run baseline, or a
spread measurement captured alongside the baseline, is what would let them be
gated again. Not attempted here.

Both runs that would have reddened CI now replay clean, and an injected 10x
regression is still caught on 19 of the 20 remaining keys, 20 of 20 at 20x.
The exception is job.acceptLedger.running.p95, whose baseline fell while its
hi_next did not, moving its floor to 16.28x. It stays gated with that floor
recorded beside the other weak keys.

Also makes the bounds checker report a zero or negative baseline as a named
rule failure instead of dividing by it and raising.
2026-08-26 14:38:16 +01:00

90 lines
2.0 KiB
JSON

{
"captured_at": "2026-08-26T11:54:41Z",
"git_sha": "8418d474a7a63aa981a4854aa94388a556517b0d",
"metrics": {
"job.acceptLedger.queued.p95": {
"unit": "us",
"value": 166.13636363636323
},
"job.acceptLedger.running.p95": {
"unit": "us",
"value": 6142.857142857149
},
"job.transaction.queued.p95": {
"unit": "us",
"value": 426.19047619047586
},
"job.transaction.running.p95": {
"unit": "us",
"value": 599.9999999999986
},
"span.consensus.accept.p50": {
"unit": "ms",
"value": 0.5287356321839081
},
"span.consensus.accept.p95": {
"unit": "ms",
"value": 8.969696969696969
},
"span.consensus.accept.p99": {
"unit": "ms",
"value": 20.800000000000026
},
"span.consensus.ledger_close.p95": {
"unit": "ms",
"value": 0.7829999999999997
},
"span.consensus.ledger_close.p99": {
"unit": "ms",
"value": 2.0299999999999896
},
"span.ledger.build.p95": {
"unit": "ms",
"value": 4.53333333333333
},
"span.ledger.build.p99": {
"unit": "ms",
"value": 9.109090909090913
},
"span.ledger.validate.p50": {
"unit": "ms",
"value": 0.06471894002114831
},
"span.rpc.ws_message.p50": {
"unit": "ms",
"value": 0.16003451676528602
},
"span.rpc.ws_message.p95": {
"unit": "ms",
"value": 0.6977397260273974
},
"span.rpc.ws_message.p99": {
"unit": "ms",
"value": 0.9757123287671235
},
"span.tx.apply.p95": {
"unit": "ms",
"value": 3.524999999999999
},
"span.tx.apply.p99": {
"unit": "ms",
"value": 5.066666666666704
},
"span.tx.process.p50": {
"unit": "ms",
"value": 0.20062219789579117
},
"span.tx.process.p95": {
"unit": "ms",
"value": 0.6100467289719625
},
"span.tx.process.p99": {
"unit": "ms",
"value": 2.758787878787877
}
},
"profile": "full-validation",
"schema_version": 1,
"window": "3m"
}