re: sample from the first moment — still flat, and the wait variant caught the ready room
early_probe defers everything expensive: no witness calibration, no per-record
labelling, and the heap scan uses bytes.find. Setup now completes in 0.5 to 0.8
seconds instead of about 25, so the first sample lands essentially at flight
detection.
It is still flat. Deployed reads 41 at flight+0.8 s and every sample after, with
the only change in 252 s being 41 to 40 when one squadron was wiped out. No
climb at any point. Under the frames reading that is expected, since the whole
phase-1 schedule would be finished within eight seconds of mission start.
The attempt to get ahead of flight detection did not work, and the reason is
worth recording. A second run started the probe before the launch and waited for
the roster to appear. It appeared with 116 records, but the numbers were
deployed 39 and craft 276, flat for the whole window. That is the ready room:
the roster is built before take-off, so waiting for it catches the pre-flight
scene, and the probe's window expired around the time flight actually began.
Waiting for the roster is not the same as catching mission start, and the test
as designed does not do what it claims.
The two runs together do suggest something, held at 🟡 because they are
different runs. The ready room shows 39 deployed and 276 craft while flight
shows 41 and 300, so two records and twenty-four craft appear between them. That
points at deployment being a single step at take-off rather than a schedule
unfolding during the mission.
Next is one run of about 400 s with the probe waiting for the roster, long
enough to span ready room, take-off and flight in a single continuous series,
which would show the 39 to 41 step directly or refute it.
This commit is contained in:
@@ -560,3 +560,55 @@ under any seconds reading it is flat there and climbs later.
|
||||
|
||||
That requires the probe's ~25 s of enumeration and calibration to happen *after*
|
||||
a first cheap sample, which is a reordering rather than new decoding.
|
||||
|
||||
---
|
||||
|
||||
# Sampling from the first moment (2026-08-24)
|
||||
|
||||
## ✅ Setup cost cut from ~25 s to ~0.5 s
|
||||
|
||||
`early_probe.py` defers everything expensive: no witness calibration (two 32 MB
|
||||
reads), no per-record labelling, and the heap scan uses `bytes.find`. Setup
|
||||
completes in **0.5–0.8 s**, so the first sample lands essentially at flight
|
||||
detection instead of 25 s after it.
|
||||
|
||||
## 🔴 Still flat: deployed is 41 at flight+0.8 s and never climbs
|
||||
|
||||
```
|
||||
+ 0.8s deployed= 41 craft=298
|
||||
+ 2.1s deployed= 41 craft=298
|
||||
… every sample to +252s …
|
||||
+252.0s deployed= 40 craft=282
|
||||
```
|
||||
|
||||
The only change in 252 s is 41 → 40, one squadron wiped out. **No climb at any
|
||||
point**, so no arrival is observable from flight detection onward — which under
|
||||
the frames reading is expected, since the whole phase-1 schedule would be over
|
||||
within 8 s of mission start.
|
||||
|
||||
## 🔴 A flaw in the `--wait` variant: it caught the ready room
|
||||
|
||||
To get ahead of flight detection, a second run started the probe *before* the
|
||||
launch and waited for the roster to appear. It did appear — 116 records — but the
|
||||
numbers were **`deployed = 39`, `craft = 276`**, flat for the whole 200 s window.
|
||||
|
||||
That is not the mission. **The roster is built before take-off**, so waiting for
|
||||
it catches the READY ROOM, and the probe's window expired around the time flight
|
||||
actually began. Waiting for the roster is not the same as catching mission start,
|
||||
and the test as designed does not do what it claims.
|
||||
|
||||
## 🟡 But the two runs together suggest deployment happens at take-off
|
||||
|
||||
| state | deployed | craft |
|
||||
|---|---|---|
|
||||
| ready room | 39 | 276 |
|
||||
| in flight (from t+0.8 s onward) | 41 | 300 |
|
||||
|
||||
Two more records and 24 more craft appear between the ready room and flight.
|
||||
These are **different runs**, so this is suggestive rather than measured — but it
|
||||
points at deployment being a single step at take-off rather than a schedule
|
||||
unfolding during the mission.
|
||||
|
||||
**Next:** one run with the probe waiting for the roster and sampling for ~400 s,
|
||||
long enough to span ready room → take-off → flight in a single continuous
|
||||
series. That would show the 39 → 41 step directly, or refute it.
|
||||
|
||||
Reference in New Issue
Block a user