From f1215ef9d90053dbcf82b3567dc69e13cadba373 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 12:50:36 -0400 Subject: [PATCH] docs(series4): REFUTE the half-period theory -- the connection dial sets a count The prediction was sharp and it was wrong. I hypothesised the connection check ran at half the status period, predicting 30 s when status is set to 60 s. Measured: 60.5 s. Recorded rather than quietly deleted. Three configurations now measured, each over many cycles: status 10 / conn 10 -> status 10.1 s conn: none ever ran 0 per cycle status 30 / conn 10 -> status 30.4 s conn 15.2 s 2 per cycle status 60 / conn 30 -> status 60.5 s conn 60.5 s 1 per cycle The status dial is honoured in all three, within ~1%. The connection dial is honoured in none. What holds across all three is a count, not a period: separate connection checks per status cycle = (status / connection) - 1 Consequences: setting the two dials equal yields ZERO connection checks, so every connection is the expensive eleven-command status read -- and that is the configuration that looks like the default. "Every 30 s" with status at 60 s gives one check per minute, half the advertised rate. No simple scale factor describes the observed cadences either (10 -> 15.2, 30 -> 60.5). Still unexplained: the phase within a cycle. At status 30 / conn 10 the two short checks landed at T+10.1 and T+25.3 where an evenly divided cycle would put them at T+10 and T+20. The count rule holds; the phase does not follow from it. Also adds a traffic table across the three configurations: 563 MB/month at 10 s/10 s, 147 MB/month at the current 60 s/30 s, against 9 MB/month for a POLL + MONITOR_STATUS check at 60 s. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 62 ++++++++++++++++++++++++---- 1 file changed, 55 insertions(+), 7 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index fa9e91d..5901d1f 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -1669,14 +1669,62 @@ FULL at T + 30.4 (+5.1) 27 consecutive connection-check gaps, all 15.1–15.3 s. That is systematic, not jitter. -**15.2 s is exactly half of 30.4 s**, and the two are phase-locked 2:1 — which -suggests the connection check is not running on its own setting at all, but at -half the *status* period. +> ⚠ **A "half the status period" hypothesis was raised here and REFUTED.** It +> predicted that with status at 60 s the connection check would run at 30 s. +> Measured: **60.5 s**. Recorded rather than deleted — the prediction was sharp +> and it was wrong. -⚠ **Hypothesis, not established.** It predicts sharply: with status at 60 s the -connection check should land at 30 s **whatever its dial says**. One capture -settles it, and it is worth settling before SFM offers any similar control — a -dial that silently does nothing is worse than no dial. +### The connection dial sets a COUNT, not a period + +Three configurations, each measured over many cycles: + +| status | connection | status observed | connection observed | separate conn checks per status cycle | +|---|---|---|---|---| +| 10 s | 10 s | 10.1 s ✅ | — | **0** (none ever ran) | +| 30 s | 10 s | 30.4 s ✅ | 15.2 s ❌ | **2** | +| 60 s | 30 s | 60.5 s ✅ | 60.5 s ❌ | **1** | + +**The status dial is honoured in all three** — within about 1%. + +**The connection dial is not honoured in any of them.** What actually holds is: + +``` +separate connection checks per status cycle = (status ÷ connection) − 1 +``` + +1 → 0 checks, 3 → 2 checks, 2 → 1 check. So the field does not set a period; it +sets how many checks fit inside a status cycle, and it is off by one. + +Consequences worth naming: + +- **Setting the two dials equal yields zero connection checks.** Every + connection is then the expensive eleven-command status check. That is the + default-looking configuration, and it is the worst one. +- **"Every 30 s" with status at 60 s gives one check per minute** — half the + advertised rate. +- The observed cadences are not multiples of the connection setting at all + (10 s → 15.2 s; 30 s → 60.5 s), so no simple scale factor describes it either. + +⚠ The *timing within* a cycle is still not fully explained. At status 30 / +connection 10 the two short checks landed at T+10.1 and T+25.3, where an evenly +divided cycle would put them at T+10 and T+20. The count rule holds across all +three configurations; the phase does not follow from it. + +**For SFM:** this is the concrete argument against exposing a dial whose +behaviour is not what it says. If a control sets an interval, it should set that +interval — and if the effective rate is derived from something else, the UI +should show the derived value, not the input. + +### Traffic at each configuration + +| status / connection | per minute | per day | per month | +|---|---|---|---| +| 10 s / 10 s | ~13 KB | **18.8 MB** | **563 MB** | +| 60 s / 30 s (current) | ~3.4 KB | **4.9 MB** | **147 MB** | +| a minimal check at 60 s | ~0.2 KB | **0.3 MB** | **9 MB** | + +The last row is `POLL` + `MONITOR_STATUS` only — enough to answer "alive?" and +"monitoring?". ### ⚠ What this means for the "won't stay connected" failure