Performance

QuicN is ahead of wireguard-go by 24% and of kernel WireGuard by 22%. QuicN sustains the same rate whether the box is encrypting or decrypting, and it holds across parallel streams (12.1 Gbit/s at two and four). The bare network link with no tunnel does more than 35 Gbit/s single-flow, so it is nowhere near the limiter here, which indicates that this is an algorithmic result. When it comes to memory, the gap among userspace tunnels is 4.5x. QuicN's memory rises for about fifteen seconds at the start of a transfer and then stays flat.

4 vCPU Alpine guests (kernel 6.18.39-0-lts) on one AMD Ryzen 9 5900X ESXi host, each given a Mellanox ConnectX-5 SR-IOV virtual function, VF-to-VF via the NIC's embedded eSwitch, iperf3 single TCP stream, 20s per run with 3s discarded; ran on 12 August 2026. Reproduces an earlier vmxnet3 (fully virtual NIC) run at the same ordering and similar margins (QuicN 11.23, wireguard-go 9.39, kernel WireGuard 8.65 Gbit/s; kernel WireGuard's performance changed with the use of a real NIC). Memory usage follows the same pattern.

Both of the fastest tunnels on the box are userspace ones. Kernel WireGuard lands at 2.28 Gbit/s here, which is not what people expect, because it processes packet by packet with no batching, while both userspace implementations move dozens of packets per system call. QuicN reaches its figure with nothing switched off: ACLs, source validation and telemetry all enabled.

One 6-core/12-thread x86 host, both endpoints in dedicated containers on it, single iperf3 TCP flow, unmodified Linux 6.12 host, QuicN 1372-byte/WireGuard 1420-byte inner MTU (the QuicN MTU is kept at its default so it supports IPv6, VLAN, PPPoE and QUIC header framing). 4 July 2026.

The most telling number is 1.49. Stock Linux gets worse as concurrency rises, while the eXpress Path has little jitter. At 2.23 Gbit/s it is delivering 94–97% of what the physical network provides, whereas the kernel path plateaus at 66%. PPPoE-XP uses 2.3 out of 8 CPU cores on this hardware.

NanoPi R6S on a live 2.5 Gbps PPPoE line, a 2.5 GbE NIC with no offloads support so the fastpath ran in generic mode. Parameters: 1492 MTU, iperf3 TCP CUBIC, 20s runs, median of three - zero errors across roughly 18 million frames. 27 July 2026.

With no kernel PPPoE anywhere, the eXpress Path transfers up to 33.9 Gbit/s download, more than 3x what the kernel stack manages on identical real NIC hardware. The kernel path shows the same top-end behaviour under concurrency as it does on the 2.5 GbE line: extra flows just queue behind its one serialised channel.

Two 4 vCPU Alpine guests (kernel 6.18.39-0-lts) on one AMD Ryzen 9 5900X ESXi host, each given a Mellanox ConnectX-5 SR-IOV virtual function, VF-to-VF via the NIC's embedded eSwitch. Single flow: kernel-both-ends used rp-pppoe in kernel mode, 20s iperf3 runs, 12 August 2026. Two flows: medians of 8 alternating paired A/B runs with variant order; each run is 30s of iperf. 13 August 2026.

Note that these are endpoint-contended comparisons on one host, not two boxes across a wire forwarding traffic generated elsewhere: iperf3 shares the same vCPUs as the data-plane threads. An earlier fully virtual vmxnet3 NIC run showed the same shape at lower resolution: kernel-to-kernel 10.4 Gbit/s against both-ends-Cosinium 15.5 (a 1.49x gap).

• Runs are interleaved between implementations rather than done in blocks so that thermal drift cannot favour whichever went first.
• A warm-up window is discarded from every run, and results are based on the mean of the observed range rather than the best-of.
• Comparison targets run in their stock configuration. For wireguard-go that is already its tuned configuration, which uses batched I/O and a thread pool.
• Security features stay on in QuicN runs. Turning off ACLs or telemetry does produce a larger number, but that is not the default behaviour, so we do not quote it.
• Both ends run identical kernels and the same datapath network interface.