perf(yip-bench): CPU-bound-regime spike (#4 go/no-go) #115

Merged

vxfemboy merged 3 commits from perf/cpu-bound-regime-spike into main

2026-07-26 04:24:09 +00:00

vxfemboy commented

2026-07-26 03:09:33 +00:00

(Migrated from github.com)

Answers the go/no-go for the #4 throughput campaign: can the yip receiver ever become CPU-bound, or is it always RTT/window-bound? If it never saturates a core, codec/MAC CPU wins can't move throughput.

Method

run-cpu-regime.sh: two netns + veth, yip tunnel between them. The receiving yipd is taskset-pinned to one core (models the 1-core EPYC target); sender + iperf get other cores. Push data B→A (UDP blast, then TCP -P 8) while sweeping netem RTT; record throughput + the pinned RX core's utilization (1.0 = one core saturated).

Result — a CPU-bound regime EXISTS

RTT	flow	Gbps	rx_cores	udp_loss
0ms	udp	1.196	0.96	80.1%
0ms	tcp	0.969	0.86	-
5ms	udp	1.222	0.97	79.8%
5ms	tcp	0.627	0.43	-
24ms	udp	1.049	0.96	82.9%
24ms	tcp	0.424	0.38	-

UDP blast pins the RX core at ~0.97 and caps at ~1.2 Gbps with ~80% drop at every RTT — a hard single-core processing ceiling.
TCP is CPU-bound at low RTT (0ms: core 0.86), window-bound at high RTT (24ms: core idle 0.38).

Implication

The earlier "CPU wins don't move throughput" verdict was specific to the 24 ms single-flow WAN path. The #4 CPU work (codec swaps, and the ~4% MAC from #58) is justified for short-RTT / regional / aggregate-parallel traffic, where the ~1.2 Gbps single-core ceiling binds. Attack the biggest RX-path slices first (TUN-write, AEAD), not SipHash.

Caveat: veth has no real NIC, so absolute Gbps is optimistic — which only makes CPU-bound harder to reach, so a positive here is robust. Full write-up: crates/yip-bench/cpu-bound-regime.md.

Answers the go/no-go for the #4 throughput campaign: **can the yip receiver ever become CPU-bound, or is it always RTT/window-bound?** If it never saturates a core, codec/MAC CPU wins can't move throughput. ## Method `run-cpu-regime.sh`: two netns + veth, yip tunnel between them. The receiving yipd is `taskset`-pinned to **one core** (models the 1-core EPYC target); sender + iperf get other cores. Push data B→A (UDP blast, then TCP -P 8) while sweeping netem RTT; record throughput + the pinned RX core's utilization (1.0 = one core saturated). ## Result — a CPU-bound regime EXISTS | RTT | flow | Gbps | rx_cores | udp_loss | |--:|--|--:|--:|--:| | 0ms | udp | 1.196 | **0.96** | 80.1% | | 0ms | tcp | 0.969 | 0.86 | - | | 5ms | udp | 1.222 | **0.97** | 79.8% | | 5ms | tcp | 0.627 | 0.43 | - | | 24ms | udp | 1.049 | **0.96** | 82.9% | | 24ms | tcp | 0.424 | 0.38 | - | - **UDP blast pins the RX core at ~0.97 and caps at ~1.2 Gbps with ~80% drop at every RTT** — a hard single-core processing ceiling. - **TCP is CPU-bound at low RTT** (0ms: core 0.86), **window-bound at high RTT** (24ms: core idle 0.38). ## Implication The earlier "CPU wins don't move throughput" verdict was **specific to the 24 ms single-flow WAN path**. The #4 CPU work (codec swaps, and the ~4% MAC from #58) **is** justified for short-RTT / regional / aggregate-parallel traffic, where the ~1.2 Gbps single-core ceiling binds. Attack the biggest RX-path slices first (TUN-write, AEAD), not SipHash. **Caveat:** veth has no real NIC, so absolute Gbps is optimistic — which only makes CPU-bound *harder* to reach, so a positive here is robust. Full write-up: `crates/yip-bench/cpu-bound-regime.md`.