mirror of
https://github.com/ruvnet/RuView.git
synced 2026-10-21 22:22:33 -05:00
Joeandclaude-flow
767c36ad12
How a node rate-limits CSI callbacks decides whether cross-node fusion works at all, because it decides whether two nodes keep the SAME frames or merely the same NUMBER of frames. We measured three gates on a nine-node ESP32-C6 fleet as a 2x2 factorial, three Latin-square blocks, every arm verified live on every node. Selecting frames by 802.11 rx_seq roughly doubled cross-node pairing over the elapsed-time gate: 0.5605 against 0.2434, +31.7 pp, reproduced in all three blocks at ~70x the measured drift floor. Two results we did not want and are reporting anyway: - Mesh-time alignment -- a gate we built and expected to be the answer -- bought +0.5 pp, about one standard deviation of noise. Indistinguishable from doing nothing. - We predicted rx_seq selection would win most on node pairs spanning a broken sync domain. Per-pair yield says the opposite: never-synced nodes gained LEAST. So it is not a workaround for broken time sync, and repairing our mesh split would probably not have closed the gap. The document leads with the method rather than the numbers, because the numbers are one house. It records the three mistakes that made an earlier attempt unreadable -- comparing different node subsets, not verifying the gate was actually live, and using frame rate as the check that a gate is working when a bucket gate makes frame rate nearly insensitive to it -- and the null run that establishes the noise floor without which none of the contrasts can be judged. run_arms.py is included so a reader can measure their own environment instead of trusting ours. That is the point of the contribution; our figures are the worked example. Stated as a trade, not a win: pairing is bought with raw frame rate. On-device edge processing was unaffected here (separately rate-limited), so the cost fell on the uplink -- but whether that is acceptable depends on what consumes the stream. Co-Authored-By: claude-flow <ruv@ruv.net>