[Japabu]

Problem

#1114's parity boot missed the ramp issue's 100 ms mark by 30 KB, 0.5 %, against the lower of two Linux runs. Its 300 ms mark, p50 and loss passed.

Finding: the bench does not resolve the miss

No sender cause was found. Three readings put the miss below what that session form can tell apart:

• The rule fails at parity one session in three. One ToyOS run sits between two Linux runs. If all three are drawn alike, ToyOS is the lowest of them a third of the time.
• The instrument steps by a read. The peer records each mark as the count before the read that passed it. It reads up to 64 KiB at a time, twice the miss.
• The marks spread more than the miss, mostly by session. In the parity boot, Linux's two runs differed by 280 KB. Across the issue's sessions Linux read 5.7–6.5 MB at 100 ms. The paced sender read 6.3–6.6 MB in tcp: new data is paced, and HyStart++ grows by all an ACK acknowledged #1114's A/B, above Linux in all three pairs, and 6.07 MB in the parity boot.

The candidate causes were checked against the RFCs and a host model:

• Initial window: RFC 6928's 10 segments, 14,480 bytes at the timestamped SMSS.
• Pacing in slow start: N = 2, as Linux's documented tcp_pacing_ss_ratio default of 200.
• HyStart++ and the first RTT samples: unchanged since tcp: new data is paced, and HyStart++ grows by all an ACK acknowledged #1114's A/B, which beat Linux.

In a model of [tcp]'s host network (card at 113 MB/s, round trips of 2, 4 and 8 ms), neither the half-window bucket nor growing cwnd at a window stop moved the 100 ms mark by 0.1 MB. RFC 9438 §4.6 admits RFC 7661 for such a stop. Pacing itself is worth 0.07–1.1 MB there. The model's receiver is [tcp]'s, not the peer's Linux, so it rules out sender-side mechanisms only within that model.

On the bench, both senders are held by the peer's window first: ToyOS for 66 ms a connection, Linux for 92–148 ms. So the first 100 ms mostly reads the receiver's window growth, which the two senders share.

Change

• osbench's upload row now carries each round's mark beside the mean: peer_received_by_<ms>ms_bytes=a,b,c,d,e. So a Linux, ToyOS, Linux session gives five ToyOS connections against ten Linux ones.
• The issue records the finding. Its exit becomes a test with a known false-fail rate. Parity means:
  • p50 within 1 MB/s of the lower Linux run;
  • nothing resent beyond a loss probe;
  • at 100 and 300 ms, ToyOS's five rounds are not ranked below Linux's ten: exact one-sided rank test p > 0.05.
• If Linux's two runs differ at p ≤ 0.05 (two-sided), the session does not decide, and an L T L T L interleaving compares runs instead.
• This replaces the exit rule set before the parity boot. The coordinator accepted it as a measurement-statistics decision.

The peer is unchanged. osbench-lan's source has not changed since the running peer was built.

Checks (at 4f52c30)

• cargo run -- --ci host: 108 steps green, exit 0.
• Host model: the head and three variants, each run exit 0.
• T14 image staged with --metal-readback, exit 2 (staged). Image sha256 c2f145b8…; it carries the new field.
• Linux osbench rebuilt at 4f52c30 with the earlier recipe, EXIT=0.
• Metal: none needed for this change. The session that judges the issue by the new exit (L1, t1 at 4f52c30, L2) is queued apart. Its result goes to the issue, which stays open until then.

Evidence: https://github.com/ToyOSOrg/evidence/tree/fafecedccf763c601a03c49422d636ed7ea498d1/r1

Risks

• The rank test treats a run's connections as exchangeable with the other runs'. The L1-vs-L2 check catches gross run effects, but not small ones.
• A pass means the bench does not resolve a difference, not that it shows equality. With 5 against 10 connections the test catches a shift of about one connection spread only part of the time.

🤖 Generated with Claude Code