Upload watch night data: one-second reads of the real push on three boxes (spike 2.1); R-1245 gets the measured floor; R-1214 dated check read (stays WATCHING); weekend-night report

documentation/audits/SPIKE-upload-watch-2026-10-23.md

@@ -53,7 +53,21 @@ it is a **lower bound** (restic over SFTP to the Storage Box may not fill the li
 
 ### 2.1 One-second samples of the real push
 
-*(filled after 02:30Z — see the section at the end, „Night data")*
+Read 2026-10-24 02:08–02:30Z, once a second, the controller container's own transmit counter (the counter the watch
+reads: `eth0` in the controller's network namespace), on the three test boxes, read only
+(`SPIKE-upload-watch-2026-10-23/night-push-1s-<box>.txt`; the reader `tools/nightsample.sh`).
+
+| Box | Sent in the 22 min | Best 10 s | 1-second peak | Counts (≥ 10 MiB in the best 10 s)? |
+|---|---|---|---|---|
+| demo-hp | 19.3 MB | **12.6 MB in 10.1 s = 10.0 Mbit/s** (02:17:32Z) | 70.3 Mbit/s | **yes** → line „at least 10 Mbit/s" |
+| demo-felhom | 3.3 MB | 3.2 MB = 2.5 Mbit/s (02:15:22Z) | 13.7 Mbit/s | no |
+| Tester 1 | 3.6 MB | 3.5 MB = 2.7 Mbit/s (02:15:40Z) | 14.7 Mbit/s | no |
+
+**What it says:** one night in three counted. The push is a burst of a few seconds (3–9 seconds above 100 kB/s), so
+even the counting night gives a low floor: 10 Mbit/s, while one second of the same push reached 70 Mbit/s. The design
+keeps the best counting night of the last 14, so the line rises only when a bigger night comes. **Consequence for the
+qBittorrent limit (R-1245):** 50 % of tonight's floor is ~5 Mbit/s on demo-hp — likely far below its real line. This is
+the known lower-bound limit (R-1247), now measured; it is written into R-1245 so the operator decides with it.
 
 ## 3. The line with a test — NOT run tonight