I have an Archer C7 v2. Is OpenWRT expected to be slower than native firmware under TCP? How about in general on various routers?
Doing an iperf test between two machines behind the router -- one LAN (wired), one WLAN (wireless). The wired one runs Windows 8.1 Pro and the wireless one runs MacOSX 10.10 (Macbook Pro late 2013), using the settings below. On Windows, I used the JPerf 2.0.2 package (GUI over iperf), while on MacOSX 10.10 I used iperf from Macports (just do "port install iperf"). In all tests, the router sits at about half a meter in front of the laptop and the position is not changed, nor anything is moving in the room, while the tests are running. Channel fading is thus low and consistent. I used channel 36 and 149 with VHT80 (all other settings left on their defaults; both channels give same results, 149 allows for higher Tx power). The "-i 1" causes iperf to report speed every second.
If you wish to test yourself, make sure the wireless machine is a true 3-stream (3x3 mimo) AC1300 801.11ac, i.e. support tru 1300 Mbps PHY rate with aggregate AMPDU support (latter should be available by default) -- using phones/tablets or devices that are not 3-stream AC1300 will not reveal differences. The other machine must be wired on a gigabit port. Otherwise you won't be able to hit 800+ Mbps.
Iperf commands:
(server, Mac): iperf -s -i 1 -w 6M
(client, Win): iperf -c 192.168.1.19 -i 1 -w 6M -l 2M
TP-Link firmware TCP results (latest TP-Link firmware from 11 Sept 2014)
[ ID] Interval Transfer Bandwidth
[216] 0.0- 1.0 sec 102 MBytes 856 Mbits/sec
[216] 1.0- 2.0 sec 104 MBytes 872 Mbits/sec
[216] 2.0- 3.0 sec 104 MBytes 872 Mbits/sec
[216] 3.0- 4.0 sec 104 MBytes 872 Mbits/sec
[216] 4.0- 5.0 sec 96.0 MBytes 805 Mbits/sec
[216] 5.0- 6.0 sec 104 MBytes 872 Mbits/sec
[216] 6.0- 7.0 sec 104 MBytes 872 Mbits/sec
[216] 7.0- 8.0 sec 104 MBytes 872 Mbits/sec
[216] 8.0- 9.0 sec 104 MBytes 872 Mbits/sec
[216] 9.0-10.0 sec 104 MBytes 872 Mbits/sec
[216] 0.0-10.1 sec 1032 MBytes 860 Mbits/sec
Done.
OpenWRT TCP results (OpenWRT 14.07 release):
[212] 0.0- 1.0 sec 46.0 MBytes 386 Mbits/sec
[212] 1.0- 2.0 sec 64.0 MBytes 537 Mbits/sec
[212] 2.0- 3.0 sec 64.0 MBytes 537 Mbits/sec
[212] 3.0- 4.0 sec 64.0 MBytes 537 Mbits/sec
[212] 4.0- 5.0 sec 56.0 MBytes 470 Mbits/sec
[212] 5.0- 6.0 sec 64.0 MBytes 537 Mbits/sec
[212] 6.0- 7.0 sec 64.0 MBytes 537 Mbits/sec
[212] 7.0- 8.0 sec 64.0 MBytes 537 Mbits/sec
[212] 8.0- 9.0 sec 48.0 MBytes 403 Mbits/sec
[212] 9.0-10.0 sec 56.0 MBytes 470 Mbits/sec
[212] 0.0-10.1 sec 592 MBytes 491 Mbits/sec
Done.
NOTE: That was the best score I managed to record. Most of the time, the speed under OpenWRT drops to 200 Mbits/s or fluctuates between 200 and 500 Mbits/s. It is never as consistent or as high as the speed under the TP-Link firmware on when using TCP.
Using UDP instead of TCP, then both OpenWRT and TP-Link firmware yield around 800 Mbits/s.. With a UDP buffer size of 1MB, iperf settings were:
(server, Mac): iperf -s -u -i 1 -w 1M -l 4K
(client, Win): iperf -c 192.168.1.101 -i 1 -w 1M -l 4K -b 850M
[SUM] 1.0- 2.0 sec 98.5 MBytes 826 Mbits/sec
[ 4] 2.0- 3.0 sec 98.5 MBytes 827 Mbits/sec 0.039 ms 1123/26350 (4.3%)
[ 4] 2.0- 3.0 sec 152 datagrams received out-of-order
[ 4] 3.0- 4.0 sec 98.5 MBytes 826 Mbits/sec 0.044 ms 1082/26292 (4.1%)
[ 4] 3.0- 4.0 sec 182 datagrams received out-of-order
[ 4] 4.0- 5.0 sec 100 MBytes 841 Mbits/sec 0.080 ms 904/26557 (3.4%)
[ 4] 4.0- 5.0 sec 160 datagrams received out-of-order
[ 4] 5.0- 6.0 sec 85.7 MBytes 719 Mbits/sec 0.030 ms 4103/26039 (16%)
[ 4] 5.0- 6.0 sec 153 datagrams received out-of-order
[ 4] 6.0- 7.0 sec 100 MBytes 841 Mbits/sec 1.580 ms 808/26478 (3.1%)
[ 4] 6.0- 7.0 sec 327 datagrams received out-of-order
[ 4] 7.0- 8.0 sec 88.1 MBytes 739 Mbits/sec 0.039 ms 3598/26151 (14%)
[ 4] 7.0- 8.0 sec 198 datagrams received out-of-order
[ 4] 8.0- 9.0 sec 85.5 MBytes 717 Mbits/sec 57.913 ms 4441/26333 (17%)
[ 4] 8.0- 9.0 sec 195 datagrams received out-of-order
[ 4] 0.0- 9.9 sec 944 MBytes 799 Mbits/sec 0.971 ms 21178/262767 (8.1%)
[ 4] 0.0- 9.9 sec 1799 datagrams received out-of-order
Question
Obviously the router itself is capable of hitting 800+ Mbits/s. I know TCP is more demanding on the CPU than UDP, so is the lower TCP throughput in OpenWRT due to the driver used?
If not, any pointers or ideas on what to try to improve it? See below things I've already tried.
- Fresh OpenWRT was flashed then the following issued: uci set wireless.radio0.htmode=VHT80; uci set wireless.radio0.disabled=0; uci commit; wifi; ... nothing else was installed or enabled.
- I tried using both open (no auth) and WPA/WPA2.
- Also tried using channel 149 so I could use 30 dBm Tx power (channel 36 was limited to 17dBm).
- Also tried setting sysctl options net.core.rmem_max=2097152, net.core.wmem_max=2097152, net.ipv4.tcp_rmem=4096 87380 2097152 and net.ipv4.tcp_wmem=4096 87380 2097152.
- Checked the received power strength under both firmwares (under MacOSX > Wireless Diagnostics > Performance) and it was pretty much the same in both cases, around -40 dBm. Channel noise is around -95/-96 dBm. So no saturation.
Nothing I tried helped getting more throughput under TCP in OpenWRT ... any clues?
Are there any known kernel modules that take such a toll in OpenWRT? What modules are safe to disable for this simple test? (assuming nothing else is needed)
Cheers.
p.s. On wired-to-wired I hit 940+ Mbits/s without much effort on both firmwares, which is expected since only the hardware ethernet switch is used in this case.
(Last edited by mastabog on 27 Nov 2014, 04:32)