USB-booted Linux and USB noise: bimodal TCP loopback latency

I've been running TCP loopback latency benchmarks on Ubuntu 26.04 booted from a USB stick (i7-13700H, 32GB DDR4) and getting a pattern I can't fully explain.
8 consecutive runs, same test parameters, no config changes between runs:

+----+----------+----------+----------+-----------+ | # | P50(µs) | P95(µs) | P99(µs) | Mean(µs) | +----+----------+----------+----------+-----------+ | 1 | 32.67 | 88.55 | 101.14 | 43.60 | | 2 | 31.60 | 87.89 | 95.94 | 39.01 | | 3 | 32.13 | 43.86 | 48.92 | 33.01 | | 4 | 34.81 | 80.68 | 93.28 | 45.58 | | 5 | 31.24 | 75.61 | 82.42 | 45.99 | | 6 | 46.53 | 71.54 | 83.40 | 48.98 | <-- jump | 7 | 64.89 | 83.68 | 92.68 | 64.08 | <-- jump | 8 | 31.58 | 68.56 | 84.73 | 36.15 | +----+----------+----------+----------+-----------+ 

See P50: 6 runs land at P50 31–34µs. The 2 jump to 46–65µs with no visible trigger. There was no disk activity, no logged contention, nothing. The benchmark itself does not touch the filesystem during measurement.

What I'm measuring: full IPC round-trip latency — a process sends a timestamped request through a router process and back, 4 TCP hops total, 10K samples per run. Pure loopback, no network traffic.

My working theory: USB I/O is occasionally competing with the TCP stack at the interrupt or scheduler level even when the filesystem is idle. Possibly the USB controller sharing a PCIe lane or IRQ line with the NIC. The bimodal shape — not a gradual spread, but two distinct clusters — suggests a periodic interrupt event rather than general noise.

What makes me less certain: the same test on Windows 11 natively installed on the same hardware gives P50 ~83µs consistently, no bimodal behavior. That's 2.5x slower than the Linux USB good runs.

That gap is hard to explain if USB noise is purely additive. If USB were inflating results upward, Linux should be slower than Windows, not faster. So either Windows has genuinely higher baseline latency for TCP loopback (which is plausible), or the Linux USB good runs are somehow faster than they should be, or both things are true simultaneously.

Two questions:

1. Is bimodal P50 in loopback benchmarks a known symptom of USB boot specifically, or just general interrupt jitter that would appear on any shared-bus configuration?
2. What's the right way to isolate whether USB controller interrupts are interfering with TCP scheduling? irqbalance output, /proc/interrupts delta between runs, something else?

For context, the tool I'm using is a standalone IPC latency benchmark. A ping-pong RTT and broadcast one-way across payload sizes.
If anyone with native Linux on SSD is curious to compare numbers against these.
The example is at