-
Notifications
You must be signed in to change notification settings - Fork 17
Benchmarks
Matthias Schiffer edited this page Aug 21, 2019
·
1 revision
Benchmarks have been made using different fastd versions ranging from v11 to v18; all these versions yield the same results.
Method | TL-WR841N/ND v9 | TL-WR1043ND v1 | TL-WDR3600 v1 | TL-WR1043ND v2 |
---|---|---|---|---|
null | 35.5 Mbits/sec | 42.1 Mbits/sec | 50.3 Mbits/sec | 62.0 Mbits/sec |
aes128-gcm | 4.08 Mbits/sec | 3.53 Mbits/sec | 4.73 Mbits/sec | 6.52 Mbits/sec |
salsa20+gmac | 15.0 Mbits/sec | 14.4 Mbits/sec | 18.5 Mbits/sec | 23.3 Mbits/sec |
salsa2012+gmac | 15.4 Mbits/sec | 14.9 Mbits/sec | 19.3 Mbits/sec | 24.1 Mbits/sec |
aes128-ctr+umac | 4.50 Mbits/sec | 3.91 Mbits/sec | 5.75 Mbits/sec | 7.03 Mbits/sec |
salsa20+umac | 21.1 Mbits/sec | 20.6 Mbits/sec | 27.7 Mbits/sec | 34.1 Mbits/sec |
salsa2012+umac | 21.8 Mbits/sec | 21.3 Mbits/sec | 29.0 Mbits/sec | 35.9 Mbits/sec |
xsalsa20-poly1305 | 6.34 Mbits/sec | 5.29 Mbits/sec | 9.19 Mbits/sec | 11.4 Mbits/sec |
null+aes128-gmac | 10.2 Mbits/sec | 10.5 Mbits/sec | 13.3 Mbits/sec | 16.6 Mbits/sec |
null+salsa20+gmac | 17.4 Mbits/sec | 16.8 Mbits/sec | 21.8 Mbits/sec | 26.7 Mbits/sec |
null+salsa2012+gmac | 17.6 Mbits/sec | 16.8 Mbits/sec | 22.1 Mbits/sec | 26.9 Mbits/sec |
null+aes128-ctr+umac | 12.6 Mbits/sec | 13.4 Mbits/sec | 18.0 Mbits/sec | 21.2 Mbits/sec |
null+salsa20+umac | 26.1 Mbits/sec | 27.2 Mbits/sec | 35.8 Mbits/sec | 43.5 Mbits/sec |
null+salsa2012+umac | 26.1 Mbits/sec | 27.2 Mbits/sec | 36.0 Mbits/sec | 43.5 Mbits/sec |
null+cipher-test | 32.2 Mbits/sec | 36.7 Mbits/sec | 45.9 Mbits/sec | 56.0 Mbits/sec |
aes128-ctr+cipher-test | 4.59 Mbits/sec | 3.90 Mbits/sec | 5.21 Mbits/sec | 7.26 Mbits/sec |
salsa20+cipher-test | 23.3 Mbits/sec | 23.6 Mbits/sec | 31.4 Mbits/sec | 38.7 Mbits/sec |
salsa2012+cipher-test | 24.8 Mbits/sec | 25.1 Mbits/sec | 32.9 Mbits/sec | 41.0 Mbits/sec |
To get reproducible results, the following setup has been used for all tests:
- All tests have been executed on OpenWrt/LEDE (the OpenWrt version doesn't seem to make a significant difference)
- The test system is booted into failsafe mode to get as little interference as possible (some kernel modules like iptables will harm performance just by being loaded)
- If the system has two separate ethernet interfaces, one (e.g. LAN) is set up with an IPv4 address (e.g. 192.168.0.1/24)
- If the system only has a single ethernet interface, two VLANs are set up to get two logically separate interfaces, then one is set up with an IPv4 address
-
tun.ko
is loaded using insmod (it is required for fastd) - fastd is set up in TAP mode, connecting over the configured IPv4 addresses
- A bridge is added, both the fastd interface and the second ethernet interface/VLAN (usually WAN) are added to the bridge
- iperf is now run in IPv6 mode over this tunnel. None of the iperf instances is run on the test system for this to get maximum performance. As the fastd tunnel is bridged with one ethernet interface or VLAN, both sides of the tunnel can be reached from outside the node.
- If the test system has two separate interfaces, you need a PC with two ethernet ports or two separate PCs for the test setup; using VLANs, a single ethernet port is enough.
- If you use a single PC, link-local IPv6 addresses can easily be used to get iperf to run over the tunnel even though both endpoint addresses are on the local machine.