Performance
Our software is built to optimise CPU cycles and minimise memory wastage. Results below also include those that went against us, because a benchmark page that only contains wins is an advertisement rather than evidence.
QuicN on a constrained instance
iperf3 tested on Linux peers, comparing userspace tunnel against userspace tunnel. Kernel WireGuard is included as a reference.
| Gbit/s | Up / down | Memory | |
|---|---|---|---|
| QuicN | 11.6 | 11.6 / 11.6 | 96 MB RSS |
| wireguard-go | 9.37 | 9.33 / 9.41 | 431 MB RSS |
| WireGuard (kernel) | 9.55 | 9.54 / 9.57 | ~0.45 MB kernel slab |
QuicN is ahead of wireguard-go by 24% and kernel WireGuard by 22%. QuicN sustains the same rate whether the box is encrypting or decrypting, and stays there across parallel streams (12.1 Gbit/s at two and four). When it comes to memory, WireGuard uses 4.5x more than QuicN.
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. Similar to an earlier run with vmxnet3 (fully virtual NIC) where QuicN delivers 11.23, wireguard-go 9.39, kernel WireGuard 8.65 Gbit/s. Kernel WireGuard's performance changed with the use of a physical NIC. Memory usage follows the same pattern.
QuicN with both endpoints on one 6-core box
Overprovisioning as seen in many environments and is the harshest test environment where the same CPU pays for encrypting and decrypting every byte. The in-kernel module results are slow in this scenario.
| Gbit/s | Memory | PQ identity | |
|---|---|---|---|
| QuicN | 12.3 | 70–80 MB RSS | ML-DSA-44 |
| wireguard-go | 12.1 – 12.4 | 363–445 MB RSS | None |
| WireGuard (kernel) | 2.28 | n/a, in kernel | None |
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.
PPPoE eXpress Path against the Linux kernel
On a 2.5GbE connection, the physical ceiling for TCP payload under PPPoE is about 2.36 Gbit/s.
- Stock Linux
- eXpress Path
- Line ceiling, 2.36
| Case | Stock | eXpress | Change |
|---|---|---|---|
| Upload, single flow | 1.55 | 2.23 | +44% |
| Upload, four flows | 1.49 | 2.23 | +50% |
| Download, single flow | 1.76 | 2.34 | +33% |
| Download, four flows | 2.14 | 2.33 | level |
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 with a 2.5 GbE NIC, no offloads support. Parameters: 1492 MTU, iperf3 TCP CUBIC, 20s runs. 27 July 2026.
PPPoE on real silicon NIC
The hardware test above is bounded by a 2.5 Gbps line, so it cannot show what PPPoE-XP itself can deliver. This test uses real NIC hardware (Mellanox ConnectX-5 SR-IOV virtual functions) between two Linux VMs on ESXi.
- Kernel
- PPPoE-XP
| Kernel | PPPoE-XP | Gain | |
|---|---|---|---|
| Single flow12 Aug 2026 | 9.1 / 9.1 | 19.5 / 18.9 | 2.1x / 2.1x |
| Two flows13 Aug 2026, paired A/B | 10.1 / 10.2 | 25.3 / 33.9 | 2.5x / 3.3x |
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).
Test Methodology
- Interleaved runs between implementations to avoid thermal drift favouring one run or the other.
- Warm-up window ignored and results are based on the mean of the observed range.
- Stock configuration - wireguard-go default is its own tuned configuration of using 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.
- Both ends run identical kernels and the same datapath network interface.
Results that do not favour us
PPPoE-XP uses a bit more CPU power
On the NanoPi R6S ARM-based SBC, at line rate PPPoE-XP uses about 2.6 of eight cores against roughly 1.3 for the slower kernel path, so it is less efficient per bit. The trade-off is worth it, because those cores were sitting idle while the upload stayed below two thirds of the connection's capacity.