From a307c837bc0d08769048d4b4ce1b2869fd2c15cf Mon Sep 17 00:00:00 2001 From: Strycher Date: Sat, 8 Aug 2026 02:53:05 -0400 Subject: [PATCH] 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. --- lib/connector/meshcore_connector.dart | 14 +++++++++----- test/connector/cli_timeout_test.dart | 7 +++++-- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/lib/connector/meshcore_connector.dart b/lib/connector/meshcore_connector.dart index 9c1862a..1fa6de8 100644 --- a/lib/connector/meshcore_connector.dart +++ b/lib/connector/meshcore_connector.dart @@ -5788,11 +5788,15 @@ class MeshCoreConnector extends ChangeNotifier { /// 4. [messageRetrievalBudgetMs], because the reply is not pushed to us. The /// radio raises `MSG_WAITING` and we must ask for it. /// - /// Command execution time is deliberately not modelled. Measured round trips - /// to a single repeater ranged from 1.65 s to 20.33 s, and the *same* verb - /// (`wifi on 30`) returned in both 2.31 s and 20.33 s, so execution cost is - /// not a per-verb constant that could be tabulated. The retrieval term is - /// what carries that tail. + /// The tail is transmit scheduling, not command execution, and neither end + /// exposes it. Measured round trips to one repeater ranged from 1.65 s to + /// 20.33 s, and the *same* verb returned in both 2.31 s and 20.33 s. On the + /// 20.33 s case the repeater stamped its reply about 5 s in and the packet + /// did not reach us for another ~15 s, so the time went into queueing on + /// both radios, not into running the command: `wifi on N` only sets a + /// deadline and returns immediately (firmware `CommonCLI.cpp` "wifi on"). + /// Nothing here is a per-verb constant that could be tabulated, so the + /// retrieval term is what absorbs it. /// /// The reply leg uses physics only. The predictor is trained on direct-message /// ACK latency, not on command round trips, so asking it about a reply leg diff --git a/test/connector/cli_timeout_test.dart b/test/connector/cli_timeout_test.dart index 44f0052..92579e9 100644 --- a/test/connector/cli_timeout_test.dart +++ b/test/connector/cli_timeout_test.dart @@ -4,8 +4,11 @@ // // Measured against rpt-01: 27 commands, 12 replies, and 4 of those 12 arrived // after the 4074 ms window had expired (6.17 s, 8.28 s, 15.52 s, 20.33 s; -// median 2.75 s). The same verb `wifi on 30` returned in both 2.31 s and -// 20.33 s, so the tail is not a per-command constant that could be tabulated. +// median 2.75 s). The same verb returned in both 2.31 s and 20.33 s. The tail +// is transmit scheduling on both radios, not command execution: on the 20.33 s +// case the repeater stamped its reply ~5 s in and the packet took another ~15 s +// to arrive, and `wifi on N` only sets a deadline before replying. So it is not +// a per-command constant that could be tabulated. // // These tests pin the budget's construction and, just as importantly, pin that // the direct-message ACK path was NOT changed.