WiFi radio test

flo · October 28, 2016, 8:08am

Don’t underestimate the Turris:

I did some quick benchmarks - the setup:

Turris Omnia: As delivered with stock 5 Ghz wifi card and antennas
MacBook Pro (Mid 2014, OSX 10.11.6)
5 Ghz Wifi set to 80 MHz channels and 27dBm (legally, thanks to DFS support - I wonder if the inital 60s radar scan is repeated any time later during usage… can’t find info on that)
No other 5 Ghz network in the neighborhood
Ridiculously ideal conditions: MacBook is ~1m directly in front of Turris with line-of-sight

MacBook -> Turris (iperf server)
Peaks at 777 Mb/s, average 645 Mb/s
WAN latency goes from ~5ms to ~15ms (SQM enabled on WAN interface)
------------------------------------------------------------
Client connecting to daller, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 5] local 10.30.12.158 port 61293 connected with 10.30.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0- 5.0 sec 388 MBytes 651 Mbits/sec
[ 5] 5.0-10.0 sec 349 MBytes 586 Mbits/sec
[ 5] 10.0-15.0 sec 366 MBytes 613 Mbits/sec
[ 5] 15.0-20.0 sec 374 MBytes 628 Mbits/sec
[ 5] 20.0-25.0 sec 400 MBytes 672 Mbits/sec
[ 5] 25.0-30.0 sec 412 MBytes 692 Mbits/sec
[ 5] 30.0-35.0 sec 463 MBytes 777 Mbits/sec
[ 5] 35.0-40.0 sec 376 MBytes 632 Mbits/sec
[ 5] 40.0-45.0 sec 365 MBytes 612 Mbits/sec
[ 5] 45.0-50.0 sec 364 MBytes 611 Mbits/sec
[ 5] 50.0-55.0 sec 373 MBytes 626 Mbits/sec
[ 5] 55.0-60.0 sec 385 MBytes 646 Mbits/sec
[ 5] 0.0-60.0 sec 4.51 GBytes 645 Mbits/sec

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=58 time=5.608 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=5.953 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=6.699 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=5.589 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=5.338 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=58 time=5.674 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=58 time=5.449 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=58 time=5.675 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=58 time=5.686 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=58 time=5.734 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=58 time=5.668 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=58 time=5.565 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=58 time=5.626 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=58 time=5.483 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=58 time=5.580 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=58 time=15.009 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=58 time=11.919 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=58 time=16.563 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=58 time=16.295 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=58 time=14.256 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=58 time=16.093 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=58 time=13.970 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=58 time=14.872 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=58 time=13.857 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=58 time=12.877 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=58 time=14.337 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=58 time=13.647 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=58 time=17.456 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=58 time=11.873 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=58 time=16.316 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=58 time=15.365 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=58 time=13.159 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=58 time=17.427 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=58 time=12.123 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=58 time=12.765 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=58 time=16.684 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=58 time=12.312 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=58 time=12.603 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=58 time=11.244 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=58 time=13.720 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=58 time=14.320 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=58 time=12.353 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=58 time=10.380 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=58 time=14.875 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=58 time=11.396 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=58 time=13.038 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=58 time=9.667 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=58 time=14.574 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=58 time=15.222 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=58 time=9.462 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=58 time=15.640 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=58 time=18.528 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=58 time=10.984 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=58 time=12.594 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=58 time=14.696 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=58 time=13.478 ms
64 bytes from 8.8.8.8: icmp_seq=56 ttl=58 time=17.183 ms
64 bytes from 8.8.8.8: icmp_seq=57 ttl=58 time=15.860 ms
64 bytes from 8.8.8.8: icmp_seq=58 ttl=58 time=15.452 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=58 time=18.088 ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=58 time=15.048 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=58 time=11.053 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=58 time=14.627 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=58 time=12.567 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=58 time=20.604 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=58 time=20.301 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=58 time=13.901 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=58 time=10.842 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=58 time=11.648 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=58 time=16.727 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=58 time=15.835 ms
64 bytes from 8.8.8.8: icmp_seq=71 ttl=58 time=11.639 ms
64 bytes from 8.8.8.8: icmp_seq=72 ttl=58 time=12.072 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=58 time=16.699 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=58 time=18.162 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=58 time=5.762 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=58 time=5.556 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=58 time=5.570 ms
64 bytes from 8.8.8.8: icmp_seq=78 ttl=58 time=5.524 ms
64 bytes from 8.8.8.8: icmp_seq=79 ttl=58 time=5.659 ms
64 bytes from 8.8.8.8: icmp_seq=80 ttl=58 time=5.749 ms
64 bytes from 8.8.8.8: icmp_seq=81 ttl=58 time=5.252 ms
^C
--- 8.8.8.8 ping statistics ---
82 packets transmitted, 82 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.252/11.959/20.604/4.370 ms

Turris -> MacBook (iperf server)
This is weird, throughput is lower and only grows slowly while latency stays flat until a spike at the test end.
Probably some broken Wifi buffering… I’m hoping to see some make-wifi-fast progress on the Turris.

Test 1:
------------------------------------------------------------
Client connecting to 10.30.12.158, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 10.30.12.1 port 42524 connected with 10.30.12.158 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  27.1 MBytes  45.5 Mbits/sec
[  3]  5.0-10.0 sec  50.9 MBytes  85.4 Mbits/sec
[  3] 10.0-15.0 sec   112 MBytes   188 Mbits/sec
[  3] 15.0-20.0 sec   166 MBytes   279 Mbits/sec
[  3] 20.0-25.0 sec   233 MBytes   391 Mbits/sec
[  3] 25.0-30.0 sec   244 MBytes   410 Mbits/sec
[  3] 30.0-35.0 sec   230 MBytes   386 Mbits/sec
[  3] 35.0-40.0 sec   232 MBytes   389 Mbits/sec
[  3] 40.0-45.0 sec   227 MBytes   381 Mbits/sec
[  3] 45.0-50.0 sec   212 MBytes   356 Mbits/sec
[  3] 50.0-55.0 sec   213 MBytes   357 Mbits/sec
[  3] 55.0-60.0 sec   213 MBytes   358 Mbits/sec
[  3]  0.0-60.0 sec  2.11 GBytes   302 Mbits/sec

Test 2:
------------------------------------------------------------
Client connecting to 10.30.12.158, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 10.30.12.1 port 42526 connected with 10.30.12.158 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  19.6 MBytes  32.9 Mbits/sec
[  3]  5.0-10.0 sec  19.5 MBytes  32.7 Mbits/sec
[  3] 10.0-15.0 sec  20.1 MBytes  33.8 Mbits/sec
[  3] 15.0-20.0 sec  29.9 MBytes  50.1 Mbits/sec
[  3] 20.0-25.0 sec  33.1 MBytes  55.6 Mbits/sec
[  3] 25.0-30.0 sec  34.0 MBytes  57.0 Mbits/sec
[  3] 30.0-35.0 sec  34.5 MBytes  57.9 Mbits/sec
[  3] 35.0-40.0 sec  46.6 MBytes  78.2 Mbits/sec
[  3] 40.0-45.0 sec  66.1 MBytes   111 Mbits/sec
[  3] 45.0-50.0 sec  65.2 MBytes   109 Mbits/sec
[  3] 50.0-55.0 sec  71.4 MBytes   120 Mbits/sec
[  3] 55.0-60.0 sec   168 MBytes   283 Mbits/sec
[  3]  0.0-60.0 sec   609 MBytes  85.1 Mbits/sec


...
64 bytes from 8.8.8.8: icmp_seq=1793 ttl=58 time=5.786 ms
64 bytes from 8.8.8.8: icmp_seq=1794 ttl=58 time=5.822 ms
64 bytes from 8.8.8.8: icmp_seq=1795 ttl=58 time=5.710 ms
64 bytes from 8.8.8.8: icmp_seq=1796 ttl=58 time=5.687 ms
64 bytes from 8.8.8.8: icmp_seq=1797 ttl=58 time=5.962 ms
64 bytes from 8.8.8.8: icmp_seq=1798 ttl=58 time=5.567 ms
64 bytes from 8.8.8.8: icmp_seq=1799 ttl=58 time=57.282 ms
64 bytes from 8.8.8.8: icmp_seq=1800 ttl=58 time=74.333 ms
64 bytes from 8.8.8.8: icmp_seq=1801 ttl=58 time=11.219 ms
64 bytes from 8.8.8.8: icmp_seq=1802 ttl=58 time=38.436 ms
64 bytes from 8.8.8.8: icmp_seq=1803 ttl=58 time=5.087 ms
64 bytes from 8.8.8.8: icmp_seq=1804 ttl=58 time=108.865 ms
64 bytes from 8.8.8.8: icmp_seq=1805 ttl=58 time=76.701 ms
64 bytes from 8.8.8.8: icmp_seq=1806 ttl=58 time=107.671 ms
64 bytes from 8.8.8.8: icmp_seq=1807 ttl=58 time=73.613 ms
64 bytes from 8.8.8.8: icmp_seq=1808 ttl=58 time=59.026 ms
64 bytes from 8.8.8.8: icmp_seq=1809 ttl=58 time=5.148 ms
64 bytes from 8.8.8.8: icmp_seq=1810 ttl=58 time=5.578 ms
64 bytes from 8.8.8.8: icmp_seq=1811 ttl=58 time=5.965 ms
64 bytes from 8.8.8.8: icmp_seq=1812 ttl=58 time=5.592 ms
...

I should probably do some proper testing with flent and a endpoint on the LAN instead of on the Turris itself…

Big_boss · October 28, 2016, 1:52pm

I’ll be waiting for your other testing.

Also have you retested the tests that you showed. I mean, those are some nice results to be honest.

adminX · October 28, 2016, 6:51pm

DFS should run every 24 hours and additionally after any radar event and has nothing to do with 27 dBm in the ETSI region. The initial scan has to do with radar detection and this runs continously in the background.

Tom · October 29, 2016, 3:25pm

Hi inteliboy, I bought the same two MikroTiK (R11e-5HacT, R11e-2HPnD) cards.

Since these cards need RP-SMA to MMCX cables, I only found this one: DeLOCK 88936.

However it is 0,32m long. Please can you let me know, which cables you are using.
I would rather like to use cables which are shorter.

Thanks, Tom

inteliboy · October 29, 2016, 4:23pm

I bought 5 pieces about 16cm each from China at aliexpress.com. Although the cables are shorter I find them too stiff due to thickness. If you don’t mind waiting you can order some cheap generic MMCX to RP-SMA cables from aliexpress.com, however, depending on your location I would try local sources like online stores with WiFi equipment and accessories.

flo · October 29, 2016, 10:26pm

So I did some more benchmarking. The HW setup is unchanged, I put the test endpoint on another Mac in the LAN or inside a Turris LXC container: it makes no difference for these tests.

The good news: the simple download/upload tests look pretty decent - 600 Mbps from Turris / 400 Mbps to Turris (consistent over several runs):

However, things go wild on a simultaneous multi-connection download+upload (RRUL) test:

Per-stream Details

DooMMasteR · October 30, 2016, 10:37pm

Same here,
I haven an ath10k based card in my laptop that only supports 2 spatial streams
iperf3 results in:
upload to turris 444 Mbits/sec
downstream from turris 473 MBit/s

so I am quite happy

Big_boss · October 30, 2016, 11:34pm

The ones that you have bought, i am still kind of confused, which ones i have to have.

MMCX (femal or male?)
RP-SMA, i know i must have the MALE one.

Pepe · October 31, 2016, 12:18am

u.fl (connectors on wifi cards, which we have - I meant COMPEX’s cards which they’re default in Omnia) - rpsma (this depends on your antenna)

Big_boss · October 31, 2016, 12:27am

Thanks, that is exactly the one.

https://nl.aliexpress.com/item/1-pcs-for-PCI-Wifi-Card-U-FL-IPX-to-RP-SMA-female-RF-Pigtail-Cable/32615723458.html

My antennas are all RP-SMA-female, the usual…

Tom · October 31, 2016, 6:37am

For the wifi cards: MikroTiK R11e-5HacT and MikroTik R11E-2HPnD you need
MMCX - RP-SMA cables. On the MMCX side, there is no male/female
option. There is only one option for the plug on the wifi card.

Cables like: “MikroTik MMCX-RPSMA pigtail” or “DeLOCK 88936” work.

quietsche · November 2, 2016, 12:23pm

Does anyone know where to get the same style antennas if upgrading to a 5 antenna setup? Or any other same (good) looking alternatives?

Tom · November 3, 2016, 6:28am

I am using “Linksys WRT004ANT” antennas …

quietsche · November 3, 2016, 6:45am

5 or 4 or 2? As I do not have to cover the vertical space (house), only horizontal (appartment) the +4/+7 should suit me well…

Tom · November 3, 2016, 9:37am

5 dedicated antennas. My home is vertically and horizontally quite demanding and the antennas are fine.

I plan to replace the Omnia pre-installed wi-fi cards with:
MikroTiK R11e-5HacT and MikroTik R11E-2HPnD.

nerdpunk · November 3, 2016, 10:02am

yeah, but then higher gain (omni-) antennas are contraproductive, look at the specs:

[quote]Beamwidth:
360° (horizontal), 30° (vertical)
[/quote]

means: less coverage up- and downstairs

Big_boss · November 3, 2016, 6:50pm

A small question to you guys, because i THINK you know a bit more about antennas then i do.

When the antennas are straight then it is just a 2.4 GHz antenna, but when they have also a twist in them, then they also receive/send 5 GHz signal. Have i understood this correctly?
The longer the antennas and every so and then a twist for the 5 GHz is right i guess right?
I still have 3 10 Dbi antennas of sitecom, which it said it was for the 2.4 GHz but a couple of months a go i accidentally took off the plastic covering and saw the antenna inside. It had twice or thrice a twist in it. So this confirms that it could also be used for 5 GHz right?

adminX · November 4, 2016, 7:22am

You can have any antenna as a straight on. This won’t be practical for long wavelengths yet there are ones with over 100 meters length. Form of an antenna gives hints but it says nothing exact about its usable frequencies.
Antennas may be shorter than they look. The case (plastic parts) depend more on style (longer is better) than on function (house the antenna).
These twists in the 10dbi are to reach the gain. Multiband antennas like the LTE ones can get quite long and have many twists and still only have a low gain. Compared to dual-band GSM ones multiband LTE ones are huge.

hdo · April 6, 2017, 9:51am

inteliboy:

WiFi performance is below the capabilities of the hardware.
I bought no-wifi 1GB version and separately bought 2 quite powerfull cards:
MikroTiK R11e-5HacT (QCA9880 chipset based)
MikroTik R11E-2HPnD (AR9582 chipset based)
and sadly the ath10k opensource driver sucks big time.
Previously I used 2.4Ghz NEXX WT3020 with MediaTek (Ralink) proprietary driver and it was able to deliever ~70Mbps over 144Mbps (20Mhz) channel.
Now with Turris on 5GHz with R11E-5HacT (capable of 1300Mbps and 28dBm) I get merely ~280Mbps.
The only chance for this setup is the proprietary QCA-WIFI driver and I hope someone will release images for Omnia with this driver as I doubt the Omnia developers will use this driver although the sources for qca-wifi are not hard to find and available here: http://dl.openwrtdl.com

Is there any progress on this? Is a better driver available? Thanks.

nerdpunk · April 6, 2017, 10:22am

it’s a proprietary firmware, the other one is also just a firmware - of unknown origin i guess

there’s no big proplem with the current firmware atm (i’m running it on several ath10k devices at least)… maybe the mikrotik card is just crap? or not able to work at 28dBm… distorted signal, whatever