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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
f1215ef9d9