3 Commits (dev)

Author	SHA1	Message	Date
Strycher	0f7a920220	fix(#533): state the flood constraint instead of a branch that never fired ... The flood arm read as though the model were consulted: if (pathLength < 0) { // Flood: trust ML, only enforce firmware formula as floor if (mlTimeout < physicsMin) return physicsMin; } return mlTimeout.clamp(physicsMin, physicsMax); It never did that. _physicsMinTimeout and _physicsMaxTimeout return the identical expression for pathLength < 0, mirroring the firmware's calcFloodTimeoutMillisFor, so a clamp between them cannot preserve a prediction. Whichever way control went, flood returned 500 + 16 * airtime. The comment described behaviour the code did not have, which is exactly the kind of load-bearing false comment that re-causes a bug later. Replaced with an explicit early return and the constraint written down. Behaviour is unchanged. Equivalence is tested, not asserted. A new group attaches a real TimeoutPredictionService, trains it on 40-56 s delivery times so any prediction is far from 1300, and checks flood is unmoved while a direct path is still clamped to its ceiling, which proves the clamp is live rather than the predictor being absent. That group was run against the pre-change branch and passes there too, so this is a simplification and not a behaviour change. Deliberately NOT decided here: whether flood should ever trust a prediction. Every round trip measured to date was 0-hop direct, so there is no flood data to decide it from. The verification needed to answer it is written up on the issue. Part of epic #473, stacked on #528, #529, #531 and #532.	2 months ago
Strycher	a307c837bc	fix(#529): correct the rationale comment, the tail is scheduling not execution ... The comment justified not modelling command execution time by claiming `wifi on 30` does real work bringing up an interface. It does not. The firmware handler sets a persistence deadline and sprintf's its reply immediately (CommonCLI.cpp, "wifi on"), so execution is near-instant. The owner caught it: he recalled reissuing the command several times against on-screen errors, not one command taking 20 seconds. The measurement supports him. On the 20.33 s case the reply carried claimed=01:56:32 against a command sent at 01:56:26.938, and the RF frame did not reach our radio until 01:56:47.271979. So roughly 5 s to reach the repeater and be answered, then roughly 15 s in its transmit queue. The tail is scheduling on both radios. No behaviour change. The budget is unchanged and still has to tolerate a 20.33 s round trip; only the stated reason was wrong, and a wrong reason in a load-bearing comment re-causes the bug later.	2 months ago
Strycher	83f6360f7e	fix(#529): give repeater CLI commands their own timeout budget ... The CLI timeout used calculateTimeout, which mirrors the firmware's calcDirectTimeoutMillisFor and estimates ONE-WAY delivery. A CLI command is a request, an execution and a reply, so the budget was structurally short. Measured against rpt-01 on 910.525 MHz / SF7 / BW 62.5k / CR 4:5, where the old window was 4074 ms: 27 commands sent, 12 replies matched, and 4 of those 12 arrived after the client had already given up, at 6.17 s, 8.28 s, 15.52 s and 20.33 s against a median of 2.75 s. calculateCliTimeout sums four terms, each with a source rather than a chosen value: outbound leg calculateTimeout, which is what it actually models cliReplyDelayMs 600, firmware CLI_REPLY_DELAY_MILLIS, unconditional reply leg the reply is a second packet the ACK formula omits retrieval budget replies are pull-based; the radio raises MSG_WAITING and the app must ask, granting itself 5000 ms per attempt across 3 retries The retrieval term is derived from the sync constants rather than restated, so the command timeout cannot drift below the layer it depends on. That is the #530 invariant holding by construction, not by two numbers being maintained in agreement. Execution time is deliberately not modelled. The same verb, wifi on 30, returned in both 2.31 s and 20.33 s, so it is not a per-command constant that could be tabulated. The retrieval term carries that tail. The reply leg uses physics only. The predictor is trained on direct-message ACK latency, so asking it about a CLI reply leg would be extrapolation; that is #534 and #535, not this change. Tests cover the construction, the never-below-retrieval invariant, growth with path length, coverage of the 20.33 s worst case actually observed, and negatively that the direct-message ACK path is untouched. Part of epic #473. Does not change the reported duration string (#531) or the stale-prefix fallback (#532), and does nothing for commands that draw no reply at all (#541).	2 months ago