Latency matrix: flavour × transport × acceptor model

Hardware epoch boundary (2026-09-18). This is the archived Xeon Gold 6154 matrix. hp now runs an Intel Xeon Gold 6254 @ 3.10 GHz. Its topology and pin map remain compatible, but no latency, throughput or floor value below is comparable with a new run or may be extended into a current hp result. Preserve these rows as their own provenance; establish a separately labelled 6254 baseline before publishing any new hp figure. See the hardware-transition record and refresh checklist.

Both NICs are measured on this box. hp has a Mellanox pair (mlxA/mlxB, 10.9.1.x) and a Solarflare pair (sfcA/sfcB, 10.9.0.x); the Solarflare (2d:00.x) has been cabled since 2026-09-08 (a DAC between its two ports). kernel runs on the Mellanox pair (kernel TCP is NIC-agnostic), vma and socketxtreme on the Mellanox, onload and tcpdirect on the Solarflare. Cells measured before that date on onload and tcpdirect do not exist; they were unmeasurable here, not unsupported.

The kernel single cells carry a receive-path window. One TCP connection at 50 000/s over the Mellanox kernel path backs up in the client's send queue behind the NIC's interrupt moderation (about one interrupt per 80 µs at that rate): with both hot loops at 100% and the server's receive queue empty, cpp/kernel/single read a p50 of 235–847 µs. Since 2026-09-09 the single-session kernel cells set SO_BUSY_POLL 50 µs on every engine socket (KERNEL_BUSY_POLL_USECS in this box's machine file, bench-run's --busy-poll-usecs), so each non-blocking read polls the NIC queue itself; the same cell reads 15.8 µs, and 15.8 µs closed against 17.7 µs before. The 32-session kernel cells stay interrupt-driven: one run each with the window was inconclusive (mono 87 vs 99 µs, pool 101 vs 55 µs, shard 78 vs 74 µs) and no paired A/B has been run. java-jni's JNI acceptor reads its session directly under the window (its epoll_wait(0) gate ignored the option: 707 µs before, 18.6 µs after). java-pure owns its socket in Java, which has no busy-poll option, so its single cell stays on the interrupt-moderated path; the .NET Pure connection sets the option itself. The Solarflare kernel path sustains the single cell at 19–20 µs without any of this. java-pure keeps the moderated path: this JDK (17.0.20) exposes no busy-poll socket option (SO_INCOMING_NAPI_ID is read-only, TCP_QUICKACK the session already sets), and net.core.busy_read exists only in the initial network namespace, so it cannot be set for a bench namespace either. Its open kernel cells are the box's interrupt-moderated path, not a client that waits for replies: the open loop offers every due slot without consulting outstanding replies (up to 123 in flight, measured), which is what the saturated verdict is reporting.

The C++ VMA pool cell is unstable and no ring setting fixes it. The C++ pool server (cpp) over VMA stalls once per run for hundreds of milliseconds across every session. A first pairing suggested VMA's ring-per-thread allocation cured it; a second pairing inverted the result, so nothing is imposed and VMA_RING_LOGIC remains an experiment knob. The cell is published with whatever verdict it earns.

Closed and open measure different things, so they order differently. A closed session sends its next order the moment the reply arrives. An open session sends on a schedule, one order per 20 µs at 50 000/s. The v4 page shows its response time by default, measured from the scheduled slot, and publishes a cell as complete on the response CVs (since 2026-09-11). The service time, measured from the actual send, is 0.1–1.3 µs less and is the one comparable with closed, so the open figures in this paragraph are service p50s. For single cells, closed is 1–7% faster: rust-pure kernel 14.90 against 16.02 µs (open v4), onload 4.95 against 5.00, vma 5.23 against 5.40, tcpdirect 4.28 against 4.36. In the closed loop the path never idles; in the open loop each order follows up to 15 µs of idle spinning, and the client also paces and records every send. Neither cause has been isolated; a closed run with a 20 µs think time would separate the two. For 32-session cells the order reverses, by a lot: 32 closed sessions keep 32 orders in flight, so each reply queues behind the others (rust-pure onload mono: 46.1 µs closed, about 32 × the server's 1.4 µs per-order cost), while at 50 000/s aggregate an order rarely finds another queued (6.71 µs service, open v4). Closed multi-session cells therefore measure saturation, not latency.

Pools on this box (2026-09-11). Since the 2026-09-11 reboot hp isolates cores 8–17 and reserves core 8 for the pool coordinator (PIN_POOL_COORDINATOR=8), as scan reserves 19. Before that the coordinator shared worker 0's core, and the live audit, for which one /proc jiffy (10 ms of CPU in a sample) makes a second burner, refused C++-engine pools whenever their front door woke there; cpp's tcpdirect and socketxtreme pools refused to start at all. The fixes that go with the reserved core: the C++ pool front door backs off and waits for room (d98e5bc1); the .NET Native bench's status thread waits 1 s per idle pass (175932c4); the .NET Pure server starts its signal and socket runtime threads before it pins itself (22c69779) and names its pool workers (f3559a0d); the live watch retries an inconclusive sample after 1 s and scores an unreadable, exiting thread as inconclusive rather than a violation (d98e5bc1, 08fa2542). Every pool cell now passes the audit in open v4 and v3 and runs closed. Onload pool tails observed in cpp, dotnet-native and rust-pure remain in their recorded rows. The 2026-09-18 rust-pure investigation directly observed a nonblocking send sleeping on the shared Onload stack lock; counter timing identifies transient nonblocking packet-pool exhaustion as the likely entry path. This is not a fixed 600 ms spin or a first-measured-run-only event: later warmup and measured phases also stalled. The Rust row's maximum averages per-run maxima, so a ~690 ms event can appear as ~230 ms. The earlier claim that spin tuning was excluded is withdrawn: the launcher's effective settings had not been verified. A server-only EF_BUZZ_USEC=1000 experiment avoided the long wait in three diagnostic sittings, but increased p99 from about 95 to 118 µs; restoring 100 µs brought the stalls back. No default or published measurement was changed. See the evidence, limitations and future-run checklist; these hp/rust-pure closed-loop results are not a general production or cross-flavour guarantee. The reserved coordinator core did not remove this separate failure; placement remains important. dotnet-native's open v3 single cells finish in about 12 s, before the audit completes a sample in which .NET has stopped starting threads, so they are refused; their published rows come from an earlier sitting. VMA shard is noshard for every flavour: VMA 9.8.80 hands every connection on a port to the first listener registered for it.

hp has ten isolated cores (8–17) since 2026-09-11, as scan has (10–19), but its map is not scan's renumbered: core 8 is the pool coordinator's, servers take 9–12, core 13 is reserved for libvma's per-process maintenance thread and kept out of every measured server and client set, and clients take 14–17. Housekeeping is 0–7.

Historical v3 archive—not the current results. Open the current shared-epoch v4 matrix.