Performance — Anchor protocol — VeilNet documentation

Test Setup

Measured in September 2026 on one 16-vCPU QEMU virtual machine running Linux 7.0, with AES-NI and no PCLMULQDQ, so AES-GCM's GHASH runs in software. Sixteen anchors ran in Docker containers on seven bridge networks. They sat behind three NAT translators, one of them symmetric, and two relays, at anchor commit 4965e6e9 in its default configuration.

Bandwidth is given as a share of a ceiling, not as a raw rate. The ceiling is the most that one core of the test host can encrypt with AES-256-GCM, and the share counts every byte encrypted, headers included. This host encrypts slowly, so a raw rate would describe the host rather than anchor.
Times are in milliseconds. p50, p90 and p99 are the median and the 90th and 99th percentiles. Cold means the first packet of a burst, and warm means a packet sent straight after it.

The Four Measurements

Measured on one test host01 / 04

% of host ceiling

Nine-tenths of the ceiling, direct or relayed

The dashed line at the right of each bar is the ceiling. Low-latency mode is tuned for latency, not throughput.

Throughput by path, as a share of the host's encryption ceiling
Path	Share of ceiling
File transfer	93.3%
Direct, one TCP stream	91.6%
Through two NATs, hole-punched	90.9%
Through one relay	90.0%
Direct, four TCP streams	89.8%
Forwarded host traffic	77–78%
Low-latency mode	61.5%

ms · p50 to p99

A relay adds about a third of a millisecond

The chart shows ping round trips, including the routing into and out of the overlay on both hosts. Below it is the one-way time from the sending anchor's interface to the receiving anchor's interface.

ms · one way, mean

End-to-end encryption is about 5% of the latency

The chart shows where one packet spends its time on a direct connection in the default mode, cold and warm.

Where one packet's time goes on the direct path, mean milliseconds
Stage	Cold	Warm
QUIC, kernel UDP and the network	0.226	0.162
Network stack and address translation	0.123	0.071
Hand-offs inside anchor	0.064	0.060
TUN write	0.048	0.018
End-to-end encryption	0.026	0.020
Virtual switch and queues	0.007	0.004

% of one core's ceiling

Each peer pair runs on its own core

The dashed line is one core's ceiling. Separate pairs run on separate cores.

Throughput

A single TCP stream between two anchors runs at about nine-tenths of the ceiling. This holds whether the stream goes direct, through one relay, or through two NATs after hole punching. A relay costs little bandwidth, because it forwards at line rate.

Share of the host's encryption ceiling

Route	Share
File transfer	93.3%
Direct, one TCP stream	91.6%
Through two NATs, hole-punched	90.9%
Through one relay	90.0%
Direct, four TCP streams	89.8%
Forwarded host traffic	77–78%
Low-latency mode	61.5%

More TCP streams between the same two anchors do not add throughput. See Scaling Across Peers.
Low-latency mode trades throughput for latency, because it sends each frame as its own datagram. Run Modes explains the trade-off.

Round-trip and One-way Latency

A round trip is a ping across the overlay, including the routing into and out of the overlay on both hosts. A relay adds about a third of a millisecond at the median.

Ping round trip, ms

Route	p50	p90	p99
Direct	0.79	1.12	1.43
Low-latency mode	0.75	1.01	1.25
Through one relay	1.10	1.56	1.96

One-way time runs from the sending anchor's interface to the receiving anchor's interface, at the median.

One way, interface to interface, p50 ms

Route	Cold	Warm
Direct	0.489	0.329
Low-latency mode	0.433	0.291
Through one relay	0.650	0.463

Per-stage Latency

On a direct connection in the default mode, one packet takes 0.494 ms one way when cold and 0.335 ms when warm, on average. Most of that time is spent in QUIC, the kernel's UDP stack and the network. End-to-end encryption takes about a twentieth of it.

One way on a direct route, mean ms

Stage	Cold	Warm
QUIC, kernel UDP and the network	0.226	0.162
Network stack and address translation	0.123	0.071
Hand-offs inside anchor	0.064	0.060
TUN write	0.048	0.018
End-to-end encryption	0.026	0.020
Virtual switch and queues	0.007	0.004

Anchor's own work takes about 0.015 ms of CPU per packet, including translation, switching, queueing and end-to-end encryption. The rest of the time goes on QUIC, system calls and thread scheduling.

Scaling Across Peers

The traffic between two anchors uses one core for encryption, so more streams between the same two anchors add nothing. Separate pairs of anchors run on separate cores, and their throughput adds up.

Share of one core's ceiling

Case	Share
One peer pair	92%
One anchor, two peers	147%
Three pairs at once	About 200%

Measuring Your Own Machines

Your figures depend on your hardware and network. To compare like with like, check which route you are measuring, and whether your CPU encrypts AES-GCM in hardware.

Check whether the route is direct or relayed

$ sudo conflux route -to anchorzvukrxk67n…
direct

Measure the round trip

$ ping -c 20 <the peer's overlay address>

You can also read round-trip times from the anchor:

The RTT column of sudo conflux peers, measured every five seconds.
anchor_rtt_seconds in sudo conflux metrics, a summary over every live connection.
anchor_path_cost_seconds, the cost of the relayed routes the anchor chose.

Check the CPU for both instructions (Linux)

$ grep -m1 -wo -e aes -e pclmulqdq /proc/cpuinfo | sort -u

For the highest throughput, run anchors on processors with both instructions. See AES Hardware Acceleration.

To measure throughput, run your usual TCP throughput tool between two machines' overlay addresses, once on a direct route and once on a relayed one. Compare the two results with each other, rather than with the figures on this page.