The T14 downloads over HTTPS through ToyOS's own stack inside its list's bound, and netstack's 64 KiB receive window is filed as the ceiling its rate sits on

issues/acpi-hold-gives-up-at-a-time-counted-from-boot-whatever-its-runner-was-given.md

@@ -36,5 +36,5 @@ The harness: `tests/toyos-rust-tests/src/bin/acpi_hold.rs`, and
 ## Exit
 
 The hold is bounded from its own start, or by the bound its runner was given,
-and a job added before it cannot red `acpi_server_events` over a line the log
+which the runner hands each job of a list in `toyos_tco::LIST_BOUND_ENV`, and a job added before it cannot red `acpi_server_events` over a line the log
 holds.

issues/netstacks-receive-buffer-caps-every-connection-at-one-64-kib-window-per-round-trip.md

@@ -0,0 +1,54 @@
+---
+status: open
+kind: defect
+opened: 2026-10-09
+---
+
+# netstack's receive buffer caps every connection at one 64 KiB window per round trip
+
+netstack gives each connection a receive buffer of 65,535 bytes (`TCP_BUFFER`,
+`userland/netstack/src/main.rs`), and the window it offers a sender is never
+more than that buffer. `toyos-net-tcp` negotiates RFC 7323 window scaling, but
+takes the smallest shift that fits the buffer in 16 bits (`Tcp::new`,
+`toyos-net-shard/tcp/src/stack.rs`), which for this buffer is 0. A sender
+then has at most 65,535 bytes in flight, and a download reaches at most
+65,535 bytes per round trip, whatever the link: about 35 Mb/s at 15 ms,
+5 Mb/s at 100 ms.
+
+A larger buffer is paid in places: `PLACE_BYTES` counts a listener's
+`LISTEN_READY` receive buffers and a stream's two, out of the eighth of memory
+netstack's places may hold.
+
+## Measured
+
+The T14, `internet_download` at `83ef5a9ae`, one boot, the link up at
+1000 Mb/s: `whole bytes=170439044 secs=38.657 mbps=35.3
+rtt_ms=[16.8 15.7 15.0 16.0 16.5] busy=0.016`, judged `PASS`. One window per
+round trip is 524.3 / `rtt_ms` Mb/s: 31.2 to 35.0 across the five handshakes,
+and the rate sits at the top of that range with the CPUs 1.6 % busy across the
+transfer. Each `rtt_ms` is one handshake, a round trip plus netstack's own time
+for a connect, so it bounds the path's round trip from above and 524.3 over it
+bounds the window's ceiling from below: a rate held at the ceiling clears that
+bound by up to the handshakes' spread, 12 % in this boot. netstack exposes no
+connection's SRTT: its `inspect` snapshot counts sockets and nothing of one.
+
+The T14 sits on a gigabit connection, wired to its router, by the owner's
+statement; the line's own rate is not measured. The goal is close to that:
+"No bar but its a gigabit connection and i would like close to that" (the
+owner, asked the line's speed).
+
+## Owner
+
+`issues/toyos-has-its-own-network-stack.md`.
+
+## Exit
+
+Both of:
+
+- A host test in `toyos-net-tcp`, at netstack's stream buffer size, that a
+  stream's SYN carries a window shift above 0 and that the window it
+  advertises with an empty receive buffer exceeds 65,535 bytes. A buffer of
+  65,535 bytes fails both.
+- A T14 `internet_download` reading after the fix, recorded here with its
+  `mbps` and `rtt_ms`. It carries no rate threshold: the owner set "No bar but
+  its a gigabit connection and i would like close to that".

issues/the-host-cannot-reach-the-t14-while-it-runs-toyos.md

@@ -4,7 +4,7 @@ kind: tooling
 opened: 2026-10-08
 ---
 
-# The host cannot reach the T14 while it runs ToyOS, and no T14 row reads its wired card
+# The host cannot reach the T14 while it runs ToyOS
 
 The development host reaches the T14 only while it runs Ubuntu. Under ToyOS no
 connection the host opens to it arrives, so every row whose boot the host had
@@ -65,11 +65,12 @@ the tree has is the flat sleep
 
 ## What stands in the meantime
 
-No T14 row reads netstack on the I219, and none reads a message the card
+One T14 row reads netstack on the I219, `internet_download`, which judges one
+HTTPS download and no count of the card's; none reads a message the card
 raised. `claim_reuses_its_remapping_entry` claims the function and gives it
 back twice and takes no traffic. So the calls #763 moved onto a claim's
-binding — the I219's interrupt records, its polls and its DMA grants, driven
-at rate — have not been read on real hardware since they landed; under QEMU
+binding — the I219's interrupt records, its polls and its DMA grants — have
+carried that download on real hardware and been read by nothing else; under QEMU
 `iommu_virtio_platform` and the suite's network tests drive the same `pcidev`
 functions through virtio-net's claim.
 

issues/the-intel-nics-room-and-wake-are-unread-on-hardware.md

@@ -10,8 +10,9 @@ netstack offers its card a frame only when the driver counts room for it, and
 where there is none it sleeps on the claim until `toyos_i219::I219::wake_on_room`'s
 cause arrives. On the I219 and the 82574 every reading of that path is the
 driver's own model (`toyos-i219/src/stub.rs`), which is Intel's documents
-written down: no image gives netstack `pci:8086:15fc`, and the harness has no
-Intel card, so neither the T14 nor QEMU's `e1000e` has run it.
+written down: the one image that gives netstack `pci:8086:15fc`,
+`tests/downloadcase`, reads none of the counters below, and the harness has no
+Intel card, so neither the T14 nor QEMU's `e1000e` has been read running it.
 
 What the documents do not say of the T14's part, and the model therefore takes
 on trust: that the PCH's MAC raises a message for `TXDW` once it is unmasked.

issues/the-lan-is-not-yet-production-grade.md

@@ -86,7 +86,8 @@ of real traffic with no error, leak or stall.
 ## Standing
 
 The bench tests that prove each exit run in the T14 suite on every change to
-the path, not once. Today none does: no T14 row reads the wired card
+the path, not once. Today none does: the one T14 row that reads the wired
+card, `internet_download`, judges none of these exits
 (`issues/the-host-cannot-reach-the-t14-while-it-runs-toyos.md`). The bench itself stays honest: the boot stick's first
 command still sometimes goes unanswered on the USB2 half of its receptacle
 (runs 84, 103, 104, 105), and everything above rests on the record it carries.