mirror of
https://github.com/Kpa-clawbot/meshcore-analyzer.git
synced 2026-09-25 22:23:50 +00:00
efiten
aabeda0f2c
TestComputeAnalyticsDistanceLockHoldDuration failed on two consecutive master commits (5430bc79at 222µs,89377333at 156µs), both passing on a re-run of the identical tree, neither touching cmd/server runtime code. The flat 150µs limit sat inside the healthy band. Measured, not assumed: healthy 156µs, 222µs, 402µs three commits, 402µs from run 35252186369 regressed 201203µs fork run 35252430017, RLock deliberately held across the whole compute A factor of 500 apart, so the limit only had to stop sitting inside the healthy band. 5ms is 12x above the worst healthy reading and 40x below the measured regression. The four numbers and the run IDs are in the doc comment. The first attempt (a1767c77) calibrated against a control where readers churned a second store the writer never locks, on the assumption that their CPU load was slowing the writer. CI measured that control at 0µs: the readers cost the writer nothing, the variance is lock handoff, and the control could not see what it was meant to subtract.5e457961replaces it. Both commits are kept in this branch's history, and issue #2038 is corrected where it argued against raising the limit. Methodology untouched: same eight readers, same 200 writer cycles, same 20000 hops and 200 paths. Merged by the interim maintainer without a second human reviewer. Not run locally: cmd/server needs cgo for the #1992 driver and this machine has no C toolchain, so CI (run 35253209412) is the check, and the mutation run above is what proves the assertion still fails on a real regression. Fixes #2038