50,000 requests/s across the whole cell: 50,000/session/s for single, or exactly 1,562.5/session/s at 32 sessions. All clients share a prepared phase epoch; cell-wide slots are 20 µs apart. Delayed sends retain their intended slots.
Temporary SCAN NIC change (2026-09-08): the Mellanox-only v4 campaign uses Mellanox for new kernel, VMA and SocketXtreme results; Onload/TCPDirect are paused while the Solarflare DAC is removed. Earlier kernel results used Solarflare, including all historical v3 rows. From 2026-09-10 the host runs net.core.busy_read=50 / busy_poll=50 (declared in the machine file; a sitting refuses otherwise), so kernel rows measured from then busy-poll on every scenario. See the campaign note and completed-cell list to identify remeasured v4 rows. The archived C++ kernel and VMA pool results completed at 19:27 and 19:29 UTC carry an additional live CPU-contention qualification: their accept coordinator shared worker 0's core during all three measured phases. They are not clean-pinning comparisons; the latency impact is not quantified. The replacement kernel/VMA pool results at 20:24:51/20:27:20 UTC verify the separate core-19 coordinator, but retain their measured instability qualifications. The rerun's live watcher recorded no placement violation.
Applies to this OPEN v4 target-throughput matrix. Every measured cell shows p50, p99, p99.9 and max for the selected latency. Service is actual client start to completed reply; response starts at the scheduled slot and includes scheduler delay. Missing values show —. All four acceptor models stay visible; highlighting compares the selected metric among visible, qualified results.
| Flavour | Transport | 1 · Single1 acceptor · 1 session | 2 · Mono1 acceptor thread · 32 sessions | 3 · PoolThread pool · 32 sessions | 4 · ShardSharded acceptors · 32 sessions |
|---|
Response (default) starts at the intended slot and includes scheduler delay. Service is actual client task start to completed reply, not server processing alone. Both show p50, p99, p99.9 and max. Rate is achieved/target per session, using the slowest session. Status distinguishes incomplete delivery, target missed (rate or scheduler delay), complete—with latency variation, and other audit warnings/failures. Observations with warnings never receive best-result highlighting.
Variation is CV% = sample standard deviation / mean × 100 across the three per-run percentile values, calculated separately for each session; each displayed CV is the worst session's value, not the CV of pooled samples. The dropdown switches service and response CVs too. Published status is complete when response p50 and p99 CV are both strictly below 10%; either CV ≥10% means complete · variation. Response p99.9 CV has no threshold; service CVs are descriptive only. This rule is the same in either latency view and never clears delivery, target or audit qualifications. Missing CV evidence is “—” and complete · CV unavailable, not an assumed pass. Only three runs are available. Original TSV statuses and run-time verdicts are retained; this publication rule does not rewrite them or the historical matrices.
Only full-size, separately validated v4 evidence belongs here. Missing cells remain unmeasured; no v3 latency or smoke value is substituted. This fixed target is not a maximum-throughput result. The workload recipe remains v3; schedule v4 is selected explicitly. Source: v4 results TSV.
not measured Highest sustained completed request/reply rate across the whole cell, established by an open-load rate sweep. Report the passing/failing rate bracket and response latency at the passing rate. This measures the configured client/server system, not an isolated engine limit.
No validated maximum-throughput sweep is available yet. The historical closed-loop test allows only one outstanding request per session and is not maximum throughput. Existing target-rate observations are not maximum-throughput results either. Candidate-run instructions and remaining validation work.
Historical RTT, reply-gated pacing and aligned-deadline OPEN v3 remain on the separate earlier matrix.
| scenario | server cores | client cores |
|---|---|---|
| 1 · single | 10 | 15 |
| 2 · mono | 10 | 11-13,15-19 |
| 3 · pool | 10-13 | 15-18 |
| 4 · shard | 10-13 | 15-19 |
isolated: 10-19 · VMA maintenance (reserved, no app threads): 14 · housekeeping (never measured on): 0-9 · Pool coordinator (separate from workers): 19