Feel free to add more data, it's easy.
Question: Up/Down, does this denote bidirectional saturating traffic, or the "uni-directiona"l maximum for each direction? With "uni-directional" I accept that there is required reverse traffic (ACKs and such) but that there is no considerable data traffic in the reverse direction.
Despite a fair amount of knowledge of networking, I was never able to set up WireGuard. The interface gets RX but no actual traffic happens.
Same as in the OpenVPN performance page: unidirectional
Since WireGuard can reach the limits of GigE with an x86_64/AMD64 and AES-NI, from my WIP notes on testing:
Packets vs. Bits
Commercial routers are generally rated in terms of packets per second (PPS), rather than bits per second of throughput. This is probably a better metric when one considers that the majority of the processing load is related to understanding the headers and making decisions about them, rather than the managing payload itself. The payload is generally copied to a buffer from the interface and later written out to another interface, without modification (with minor exceptions for the headers and checksums, especially when NAT is in play).
As many home users think of bandwidth and not switching speed, and that their packets are often large, or at the MTU of their upstream link, these tests will use bandwidth as a measure.
Ethernet interfaces have their default, 1500 MTU.
A GigE link can't provide a throughput of 1,000 Mbps using TCP or UDP. There are headers, inter-packet gaps, and other overhead at the various layers that limit throughput. For typical IPv4 links, 940-950 Mbps is the highest achievable throughput for GigE without using "jumbo frames". See, for example, http://rickardnobel.se/actual-throughput-on-gigabit-ethernet/
For the purposes of this discussion, the rough numbers of
- TCP -- 940 Mbps throughput limit
- UDP -- 950 Mbps throughput limit
will be used.
IPv6 vs. IPv4 and Other Effects
In many cases, IPv6 has slightly larger headers than does IPv4. An IPv6 link will have slightly lower throughput than the IPv4 links tested here.
VLAN tagging, QinQ, or the like often add a few bytes to the on-wire packet. These impacts are on the order of a percent and are not examined in this study. For example, an 802.1Q (VLAN) tag adds 4 bytes to the over 1500 bytes of a "full" Ethernet frame, a fraction of a percent.
This isn't a "scholarly research paper", but more intended to provide general guidance. If you're within, say, 10% of the limits, you're probably too close for robust operation.
WireGuard has its own set of encapsulation, which typically reduces the achievable bandwidth further.
WireGuard sets the interface MTU to 1420. This reduces the throughput by a factor of roughly 1420/1500 ~ 94% (ignoring fragmentation overhead)
- WireGuard -- 900 Mbps throughput limit
I've written a quick n' dirty tutorial here which might help
Great summary. The actual limits are relatively easy to calculate though:
IPv4, Ethernet, TCP/IPv4 goodput:
1000 * ((1500-20-20)/(1500+38)) = 949.28 Mbps
IPv6, Ethernet, TCP/IPv4 goodput:
1000 * ((1500-40-20)/(1500+38)) = 936.28 Mbps
That is a reduction by ~1.3 percentage-points. Any additional "games" like VLAN tags or RFC 1323 timestamps will result in lower throughput.
e.g. for IPv4
1000 * ((1500-20-20-12)/(1500+38+4)) = 939.04 Mbps
1000 * ((1500-40-20-12)/(1500+38+4)) = 926.07 Mbps
Any VPN will essentially add one more layer of TP/IP headers as well as its own headers...
With payload MTU 1420 on a MTU1500 carrier, I would expect
1000 * ((1420-20-20)/(1500+38)) = 897.27 Mbps for IPv4
1000 * ((1420-40-20)/(1500+38)) = 884.27 Mbps for IPv6
as best-case payload goodput through the VPN tunnel.
That essentially confirms your numbers (but also shows how to calculate them)
Why 1500 + 38? Well, that is simply the sum of:
7 byte preamble
1 byte start of frame delimiter
6 bytes destination MAC address
6 byte source MAC address
2 byte Ethertype header
4 byte frame check sequence
12 byte equivalent inter frame gap
7+1+6+6+2+4+12 = 38 (see e.g. https://en.wikipedia.org/wiki/Ethernet_frame)
gl-inet b1300(ipq4029), as receiver, Destktop computer as sender, could reach 320Mbits.
b1300 as receiver, iPhone8 as sender, could reach 220Mbits.
From the result table from Mikrotik
80kpps is sufficient to reach Gigabit speeds on 1500MTU
|Ethernet test results|
|RB750GL||AR7242 1G all port test|
|Mode||Configuration||1518 byte||512 byte||64 byte|
|Bridging||none (fast path)||81.2||986.1||178.4||730.9||194||99.3|
|Bridging||25 bridge filter rules||51.5||625.5||52.3||214.3||53.7||27.5|
|Routing||none (fast path)||81.2||986.1||167||684||183.7||94.1|
|Routing||25 simple queues||81.2||986.1||88.5||362.4||92.8||47.5|
|Routing||25 ip filter rules||37.6||457||38.4||157.1||37.5||19.2|