Jump to content

Wi-Fi performance and known issues on SBC

tkaiser
 Share

Recommended Posts

tkaiser

tkaiser

Posted
Posted

As already done with other topics this will be the start of a new thread collecting more information over time.

 

Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here.

 

As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports:

 

  • RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1)
  • Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi)
  • RealTek RTL8723BS (used on Pine64+ and on CHIP for example)
  • RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi)

 

The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg.

 

  • Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance)
  • Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals)
  • Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run)

 

So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible).

 

Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking).

 

Now the results:

 

NanoPi Air with el cheapo Xunlong aerial, AP6212 module, Kernel 3.4.113, no BT configured: 39 Mbits/sec and 188 retransmits on average. Full log: http://sprunge.us/aPXb

 

  Reveal hidden contents

 

Pine64+ with same el cheapo Xunlong aerial, RTL8723BS module, Kernel 3.10.104, no BT configured: 39 Mbits/sec and 58 retransmits on average. Full log: http://sprunge.us/EffO

 

  Reveal hidden contents

 

Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: http://sprunge.us/dWJV

 

  Reveal hidden contents

 

ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: http://sprunge.us/Njhi

 

  Reveal hidden contents

 

How to interpret the results?

 

  • The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead! ;) ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on)
  • All 3 onboard Wi-Fi chips perform identical. This is due to single antenna 2.4 GHz Wi-Fi: 65Mbps bit rate resulting in ~40 Mbit/sec TCP/IP throughput with ideal/good/identical environmental conditions
  • The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput

 

Next steps:

 

Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set).

 

But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)

3
tkaiser

tkaiser

Posted
  • Author
Posted

Small update: Tried two more locations within the same building with OPi Lite and the other board with RTL8192CU MIMO dongle:

 

Location 1: 4 meters away, 2 walls in between, wall angle approx. 30°

 

Orange Pi Lite: 33 Mbits/sec on average

  Reveal hidden contents

 

ODROID-C2 with MIMO USB dongle: 51 Mbits/sec on average

 

  Reveal hidden contents

 

Location 2: 5 meters away, 2 walls in between, different direction compared to prior location.

 

Orange Pi Lite: 23,5 Mbits/sec on average:

 

  Reveal hidden contents

 

ODROID-C2 with MIMO USB dongle: 31.4 Mbits/sec on average

 

  Reveal hidden contents
1
tkaiser

tkaiser

Posted
  • Author
Posted

EDIT: Silly me forgot to disable Wi-Fi powermanagement. Will redo all tests now and update results in a few minutes.

 

I wanted to test with RPi Zero W but since the board is still not here I'm testing with RPi 3 now (uses same Wi-Fi/BT chip and also a small onboard antenna). I upgraded the kernel to latest available version 4.9.13-v7+ and applied all other updates. Some log output here.

 

All tests were done as above, I simply put the Raspberry in the 3 different rooms at exactly the same position and fired up the same set of tests again:

 

RPi 3 being 50cm away from AP: 37.4Mbits/s on average and over 3000 retransmits when testing in RX direction.

  Reveal hidden contents

 

Location 1: 4 meters away, 2 walls in between, wall angle approx. 30°: 10.4Mbits/s on average, a lot of retransmits and already ICMP packet losses.

  Reveal hidden contents

 

Location 2: 5 meters away, 2 walls in between, different direction compared to prior location: 6Mbits/s on average, a lot of retransmits and working remotely over SSH felt pretty sluggish.

  Reveal hidden contents
tkaiser

tkaiser

Posted
  • Author
Posted

Now repeating the test with RPi 3 at all 3 locations again. I tested first with powermanagement disabled just to realize that not that much changed. So I decided to write a small script to automatically test through 60 second iperf3 iterations in each direction (TX/RX) with enabled and later disabled powermanagement. This will be repeated 4 times each and end result will simply be used as an average value:

 

Next to AP:
powermanagement on:  39.22 Mbits/sec 
powermanagement off: 39.26 Mbits/sec

4 hours ago (see above): 37.4 Mbits/sec

 

Location 1:
powermanagement on:  20.17 Mbits/sec
powermanagement off: 22.72 Mbits/sec

4 hours ago (see above): 10.4 Mbits/sec

 

Location 2:
powermanagement on:  12.14 Mbits/sec
powermanagement off: 11.89 Mbits/sec

4 hours ago (see above): 6 Mbits/sec

 

So for whatever reasons results do not vary that much depending on powermanagement being enabled or disabled. But the numbers with enabled powermanagement from a few hours ago were a lot lower if tested in remote rooms. I thought what might have been different and two things came to my mind:

  • different board placement affecting efficiency of RPi 3's onboard antenna
  • a DECT handset lying just in between RPi and AP in location 2

So I put the handset back and re-tested:

 

Location 2 with DECT handset next to RPi 3:
powermanagement on:  12.02 Mbits/sec
powermanagement off: 11.74 Mbits/sec

 

Obviously other influences are responsible for the drastic change in numbers or powermanagement settings work somehow differently.

 

 

 

Bash script to test this (tested in Raspbian but should work with any recent Armbian installation too): 

#!/bin/bash

Test() {
	iwconfig wlan0 power $1
	sleep 5
	iperf3 -c 192.168.83.146 -t 60 | egrep "sender|receiver" >>${tmpdir}/$1.txt
	sleep 5
	iperf3 -R -c 192.168.83.146 -t 60 | egrep "sender|receiver" >>${tmpdir}/$1.txt
	iwconfig wlan0 
} # Test

tmpdir=$(mktemp -d /tmp/check-wifi.XXXXXX)
for i in on off on off on off on off ; do
	Test $i
done
unset LANG
on_average=$(awk 'BEGIN {FS = " "} ; {sum+=$7} END {printf ("%0.2f",sum/16)}' ${tmpdir}/on.txt)
off_average=$(awk 'BEGIN {FS = " "} ; {sum+=$7} END {printf ("%0.2f",sum/16)}' ${tmpdir}/off.txt)
echo -e "powermanagement on:  ${on_average} Mbits/sec\npowermanagement off: ${off_average} Mbits/sec\n"
echo -e "powermanagement on:  ${on_average} Mbits/sec"
cat ${tmpdir}/on.txt
echo "powermanagement off: ${off_average} Mbits/sec"
cat ${tmpdir}/off.txt
rm -rf ${tmpdir}

 

tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/8/2017 at 5:15 PM, tkaiser said:

Obviously other influences are responsible for the drastic change in numbers or powermanagement settings work somehow differently.

Expand  

 

Just to check the above thoughts I tested with the script on OPi Lite again. Only in 'Location 2' where results from yesterday were 23.5 Mbits/sec on average. Now the script reports

powermanagement on:  24.59 Mbits/sec
powermanagement off: 27.04 Mbits/sec

 

In fact powermanagement can not be enabled with legacy 8189fs driver (see messages below) so the difference is just result variation. And the same can be seen also from script output below since sometimes bandwidth drops down to even just 8.x Mbits/sec. So as expected the environment matters a lot, a single neighbor with a Wi-Fi active on same or nearby channels can ruin bandwidth/performance anytime:

  Reveal hidden contents

 

Time to stop for today. I got notification from buyzero.de that my Zero W is ready to be shipped so next try is then with new Raspberry Zero's onboard Wi-Fi (according to RPi folks antenna should be better than the one on RPi 3 but to be honest: I don't expect good results in locations 1 and 2 as well since no U.FL connector ready for a real antenna is on the PCB)

tkaiser

tkaiser

Posted
  • Author
Posted

Next round of tests in 'location 3' (still 5m away from AP with 2 walls in between, 1 m next to 'location 2' but with less troublesome stuff between devices and AP). I use the script from above to see whether enabling/disabling Wi-Fi powermanagement does change anything (or is possible at all). Obviously enabling/disabling on RPi 3 has no effect (brcmfmac driver), with RTL8189FTV and RTL8192CU is was not possible (same error message from iwconfig: 'Error for wireless request "Set Power Management" (8B2C) : SET failed on device wlan0 ; Operation not permitted.'), only with AP6212 (using legacy kernel dhd module) there were huge differences in performance.

 

I chose two rounds of tests at different times of the day. The first ran was shortly after midnight and the 2nd run started at 10:00 in the morning. This time I tried to find optimal antenna position but obviously that did not work that great with the TL-WN823N dongle (I have to admit that I slightly changed antenna positions between 1st and 2nd run, also not the best idea).

 

Software settings remained the same to before (so you can check dmesg output and so on above) and boards were tested one at a time (test execution lasts ~20 minutes which is also bad since environmental conditions between different test runs can change in between since for example the neighbour next to me transfers 15 min large amounts of data in his Wi-Fi interfering with mine and ruining performance in my network)

 

Results as follows, on the left nightly results as averaged iperf3 throughput numbers followed by those from now. 

 

NanoPi Air, AP6212 module, external small vertical aerial: 

powermanagement on:  5.53 / 5.16 Mbits/sec
powermanagement off: 30.14 / 14.66 Mbits/sec

 

Orange Pi Lite, RTL8189FTV module, external small vertical aerial: 

powermanagement on:  30.47 / 32.41 Mbits/sec
powermanagement off: 30.57 / 32.56 Mbits/sec

 

ODROID-C2 with TP-Link MIMO TL-WN823N dongle, RTL8192CU module, upright position: 

powermanagement on:  34.90 / 48.51 Mbits/sec
powermanagement off: 35.34 / 49.27 Mbits/sec

 

RPi 3, BCM43438 module, onboard antenna oriented obviously properly: 

powermanagement on:  35.42 / 25.59 Mbits/sec
powermanagement off: 34.56 / 25.13 Mbits/sec

How to interpret the results?

  • Powermanagement on/off matters at least with AP6212. With the other implementations there was no difference and numbers for on/off are just result variation. Further investigation needed whether it's just not possible adjusting PM settings with iwconfig or if it's not possible at all
  • Environmental conditions matter at lot. Between the two test runs nothing regarding software/settings has changed, it was just different time of the day and slightly moving around antennas/boards. IMO it's already pretty obvious that this sort of 'performance' testing in real-world environments is too stupid to be continued since numbers depend highly on stuff you can't control.

When RPi Zero W arrives I will add it to the test setup and move the whole setup to 'location 4' (will have to ask my neighbour to host the cardboard box with the 5 SBC inside). And then I might rewrite the testing script so that I can test through each board every 60 seconds to minimize external temporary influences.

 

Also interesting whether performance of TL-WN823N dongle improves when operated horizontally and not upright (Edit: nope). Same with Raspberries and their onboard antenna but here it seems upright position is better (at least when comparing the average 30 Mbits/sec from this test with the results from yesterday with RPi 3 just lying randomly around: 6 and 12 Mbits/sec)

1
tkaiser

tkaiser

Posted
  • Author
Posted

Finally testing 'location 4': 11m away from my AP in neighbour's flat with 3 walls and some chimneys in between.

 

NanoPi Air, AP6212 module, external small vertical aerial: 

powermanagement on:  2.38 Mbits/sec
powermanagement off: 3.46 Mbits/sec

 

Orange Pi Lite, RTL8189FTV module, external small vertical aerial: 

powermanagement on:  4.90 Mbits/sec
powermanagement off: 4.49 Mbits/sec

 

ODROID-C2 with TP-Link MIMO TL-WN823N dongle, RTL8192CU module, horizontal position and antenna oriented towards AP: 

powermanagement on:  18.43 Mbits/sec
powermanagement off: 18.99 Mbits/sec

 

RPi 3, BCM43438 module, onboard antenna oriented obviously properly: 

powermanagement on:  3.88 Mbits/sec
powermanagement off: 4.02 Mbits/sec

Some notes:

 

1) Still 'powermanagement on/off' has no meaning except for NanoPi Air since for the other boards it's just an example for result variation (to remember to never trust any 'benchmark' numbers you find on the net)


2) RPi 3 lost connection to AP in between (automagically re-established by network-manager a few minutes ago). That's the 'valley' left to the middle of this RX/TX graph (green are signals emitted from Fritzbox AP, blue are signals received and 'foreign' signals):
Bildschirmfoto%202017-03-09%20um%2012.08

 

3) Interestingly the difference between enabled/disabled powermanagement doesn't matter that much any more with AP6212 in this scenario (I guess I'll have to compare ping roundtrip times to get the full picture?)


4) Cheap OPi Lite with RTL8189FTV is the best single antenna performer here. But results differed a lot, there were some periods of time where 60 second average iperf3 numbers exceeded 13 Mbits/sec:

  Reveal hidden contents

 

5) The winner is the TL-WN823N USB dongle since... 2x2 MIMO is useable here. Two antennas instead of one greatly improve performance in this scenario. Please note that this requires an 802.11n capable AP that also features at least the same count of antennas!

 

 

Edit: As outlined in 3) above I tried to test ping roundtrip times with AP6212 and Wi-Fi powermanagement enabled/disabled. First try from location 4 (neighbour) with active PM and 120 seconds ping: 

rtt min/avg/max/mdev = 16.347/102.990/321.107/67.430 ms

Then NanoPi Air disappeared from the net and never reconnected back. So I put the boards back to my home and tried it in 'location 1' with NanoPi Air again. First numbers are with PM on, second off: 

rtt min/avg/max/mdev = 3.566/77.707/342.230/44.283 ms
rtt min/avg/max/mdev = 1.902/3.780/32.376/4.540 ms

So obviously for doing anything interactive over Wi-Fi (eg SSH) PM disabled is a great idea (average ping times 4 ms vs. 78 ms!). I tested then with RPi 3 (same Wi-Fi module but here mainline kernel driver and not dhd) with PM on/off. Here only minimum roundtrip times increased with enabled PM but also 5% packet loss occured: 

rtt min/avg/max/mdev = 4.682/55.697/409.561/97.636 ms
rtt min/avg/max/mdev = 1.653/59.969/493.176/65.494 ms

 

tkaiser

tkaiser

Posted
  • Author
Posted

And another small update regarding the test setup. AP is a Fritzbox 7390 with latest firmware in a not so ideal location (mounted vertically in a wooden cabinet approx.  50 cm above the floor and 30cm next to another Fritzbox used as DSL modem and DECT basestation). The AP is configured to allow '100%' TX power (but based on the results above I would assume it's trying to play 'green' from time to time). The host all tests are running against is a virtualized Ubuntu running 'iperf3 -s' and the ESXi host is connected through GBit Ethernet to one of the Fritzbox' GBit LAN ports.

 

The AP is configured to allow 802.11n/g (no 802.11b!) in 2.4GHz band and to choose best channel possible (always 13 since least utilized compared to the other ones):

Bildschirmfoto%202017-03-09%20um%2013.06

 

So while this is a pretty 'normal'/real-world setup it's also not suited to do reasonable testing. I might need a lab environment where external influences can be minimized or at least controlled (not possible at all here) and a less intelligent AP too. But hey, why bother? Single antenna 2.4GHz Wi-Fi in crowded areas was already known as almost broken before and the few tests just verified well known facts.

 

From an Armbian (software) point of view we know that drivers/settings for onboard Wi-Fis that can be found on the boards we support seem to fit. Also maximum performance possible is defined by physical limitations (65Mbps bit rate on all boards with single antenna 2.4GHz Wi-Fi define ~40 Mbits/sec with TCP/IP max, theoretically 130Mbps on Lamobo R1 should show better results but reality looks different there). Real-world performance does not depend on driver/settings but obviously on physical/environmental conditions (type/orientation/position of antenna, utilization of Wi-Fi channels due to interference caused by other Wi-Fi devices or  stuff like DECT, microwave ovens, USB3 peripherals near the device/AP)

 

So what to look into next (real question since I still feel being a Wi-Fi noob):

  • powermanagement settings?
  • TX power settings (regulatory domain stuff, real power available)?
  • recommendations for capable USB dongles that work out of the box (mine does with Armbian)?
  • what did I miss?
tkaiser

tkaiser

Posted
  • Author
Posted

In the meantime my Zero W arrived and it took me only 1 hour to set up Raspbian headlessly on the device: 

 

 

Quick Wi-Fi test made in 'location 1' using the well known script from above (still not showing differences regarding powermanagement since this also has no effect on the Zero W -- it's still just result variation):

 

RPi 3 (kernel 4.9.13-v7+): 

powermanagement on:  23.36 Mbits/sec
powermanagement off: 22.54 Mbits/sec

 

RPi Zero W (kernel 4.4.50+): 

powermanagement on:  28.54 Mbits/sec
powermanagement off: 27.68 Mbits/sec

 

RPi Zero W (after kernel upgrade to 4.9.13-v7+): 

powermanagement on:  24.58 Mbits/sec
powermanagement off: 25.49 Mbits/sec

 

So throughput is the same or at least not lower (tests done all at different hours so not comparable since uncontrolled environment) and that's also a good reason to not further waste time with RPi tests. To my surprise onboard aerials of both WiFi equipped RPi work quite well but can't overcome 2.4GHz single antenna limitations of course. For some numbers with more antennas, 5GHz too and also 802.11ac see here for example: https://netbeez.net/2016/06/01/iperf-wifi-comparison-on-raspberry-pi-raspberry-pi-3-vs-asus-vs-hawking-vs-linksys-vs-tp-link/

1
frottier

frottier

Posted
Posted

I did some tests with the NEO Air in the recent days, borrowing the antenna from an OPi Zero. Since I experienced some serious lag while typing over ssh, one of the first moves was putting the thing line of sight to the router. This helped a little, but not much.

 

Now I have been playing with iperf and several different setups. I have a second antenna that came with an OPi One. It's the same model that comes with the Zero, but seemed to double the performance. I saw a jump from 10 MBit/s to 20 MBit/s.

 

Then I tried putting an old harddisk behind the antenna as as some sort of makeshift reflector (varying the distance as well). In one case it seemed to boost the signal, iperf went from something around 20 MBit/s to 30 MBit/s. Also, placing the HDD between the antenna and the router significantly decreased the signal.

 

Orienting the antenna differently also had an effect. At one point performance even went down to 1 MBit/s. That's when I realised the u.FL-connector was no longer properly connected.

 

So here is my takeaway: While they might do the job, OPi's stock antennas may vary in quality. I guess there is no quality check at the end of the assembly line. Also, it is very easy to screw up things. The consumer mindset -- plug it in in and expect it to work flawlessly -- is certainly not the right approach here.

 

The good news is: To a certain degree you can improve things by optimizing the antenna. I see a bright future for tinfoil reflectors and cantennas. . .

:P

 

Boring details: There are more than 50 Wifis in the 2,4 GHz band visible at my place, so none of this qualifies as a science experiment. When using iperf, distance to the router was apr. 4 metres through air and a brick wall. Above ratios came from iperf's default mode. Reverse operation (iperf3 -R) makes roughly a +10 MBit/s difference.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/9/2017 at 10:22 PM, frottier said:

I have a second antenna that came with an OPi One. It's the same model that comes with the Zero, but seemed to double the performance. I saw a jump from 10 MBit/s to 20 MBit/s.

Expand  

 

Maybe that was just 'casual benchmarking': you benchmark A, but actually measure B, and conclude you've measured C?

 

I exchanged the cheap Xunlong antenna on OPi Lite now with a much larger one and repeated the 2 tests from above: 50 cm next to the AP througput increased from 41.5 Mbits/sec to 44.8 Mbits/sec (so antenna seems to be 'better') and then I repeated test with 'location 4' at my neighbour's place, 11m away. With Xunlong antenna I got this a few hours ago: 

powermanagement on:  4.90 Mbits/sec
powermanagement off: 4.49 Mbits/sec

When I tested now again with the larger antenna, numbers were worse. So I decided to repeat the test one more time and then once again. These are the results of these 3 running within one hour: 

powermanagement on:  3.27 Mbits/sec
powermanagement off: 3.03 Mbits/sec
powermanagement on:  5.21 Mbits/sec
powermanagement off: 5.71 Mbits/sec
powermanagement on:  8.08 Mbits/sec
powermanagement off: 7.55 Mbits/sec

Nothing I would have under my control changed so we're talking about external influences (maybe his TV set, maybe something else, who knows). 2.4GHz single antenna Wi-Fi is a shit show in crowded areas anyway (I collected here 139 Wi-Fi networks and only 14 of them are in the 5 GHz band) so why bother? But if you're interested in improving things it's a good idea to monitor at least 'iwconfig' output in parallel and always check 'Bit Rate' and the 3 metrics from 'Link Quality' line. Sample output: 

wlan0     IEEE 802.11bgn  ESSID:"Snort-Honeynet"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.472 GHz  Access Point: BC:05:43:BE:C1:E7   
          Bit Rate:65 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=65/100  Signal level=64/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

I already thought about writing a daemon parsing this data together with iperf3 performance numbers to feed into RPi-Monitor but without a controlled environment it's not worth the efforts. If you're looking for Wi-Fi performance forget about onboard, single antenna Wi-Fi in 2.4 GHz band. It's that simple. :)

 

BTW: At work we consider everything below 100 Mbits/sec as broken. But customers carrying around MacBooks expect wireless to be as fast as wired connections and Apple eases this due to early adoption of new Wi-Fi standards, 5GHz support and putting enough antennas into MacBooks so that MIMO and 'antenna diversity' do work.

Ford Prefect

Ford Prefect

Posted
Posted

Hi
The channel used in the 2.4 GHz band is important.

High speed WIFI modes are normally impossible on channels close to the band borders like

1 or 13 because the spectrum of the signal would be out of band.

Depending on the drivers used on both sides this can lead to errors of interpretation.

 

tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/11/2017 at 10:42 AM, Ford Prefect said:

High speed WIFI modes are normally impossible on channels close to the band borders like 1 or 13 because the spectrum of the signal would be out of band.

Expand  

 

Huh? Care to elaborate on that? What are you referring to with 'out of band'?

 

Common knowledge (most AP owners unfortunately aren't aware of) is to use only 1, 6 and 11 where 1-11 are allowed or 1, 5, 9 and 13 where 12/13 are also allowed. The band is 2.4-2.5 GHz, channel width is 22MHz and interferences are well known. That's the reason channel 1 is specified at 2412 MHz and will therefore interfere with channel 2 and 3 (so any AP choosing channel 3 for example is set up moronically to interfere with both Wi-Fis on channel 1 and 5/6):

1440px-2.4_GHz_Wi-Fi_channels_(802.11b,g

 

In my environement with totally overcrowded 2.4Ghz band (counted 139 networks within 48 hours) channel 13 is the only reasonable choice (AP's 'auto channel' settings checks every few hours and constantly remains at this channel due to least polluted).  

 

Some details/explanations:

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 3/11/2017 at 10:42 AM, Ford Prefect said:

High speed WIFI modes are normally impossible on channels close to the band borders like

1 or 13 because the spectrum of the signal would be out of band.

Expand  

This depends may depend on HW capabilities and driver settings - either HT40+ and HT40- can be used on all channels, so additional channel will be either lower or higher than primary channel.

 

Edit: 

# ht_capab: HT capabilities (list of flags)
# LDPC coding capability: [LDPC] = supported
# Supported channel width set: [HT40-] = both 20 MHz and 40 MHz with secondary
#	channel below the primary channel; [HT40+] = both 20 MHz and 40 MHz
#	with secondary channel above the primary channel
#	(20 MHz only if neither is set)
#	Note: There are limits on which channels can be used with HT40- and
#	HT40+. Following table shows the channels that may be available for
#	HT40- and HT40+ use per IEEE 802.11n Annex J:
#	freq		HT40-		HT40+
#	2.4 GHz		5-13		1-7 (1-9 in Europe/Japan)
#	5 GHz		40,48,56,64	36,44,52,60
#	(depending on the location, not all of these channels may be available
#	for use)
#	Please note that 40 MHz channels may switch their primary and secondary
#	channels if needed or creation of 40 MHz channel maybe rejected based
#	on overlapping BSSes. These changes are done automatically when hostapd
#	is setting up the 40 MHz channel.

 

tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/11/2017 at 1:03 PM, zador.blood.stained said:

I'm assuming this is what @Ford Prefect meant by "high speed Wi-Fi modes".

Expand  

 

Well, HT40 with 2.4GHz band in 2017 means normally quite the opposite: less performance for Wi-Fi users at least when there's more than 2-3 Wi-Fi networks in the same location. I dropped the idea already years ago but anyway, let's give it a try again:

 

While I consider HT40 with 2.4GHz highly antisocial (see below) I just forced my AP to behave antisocial and enforced HT40 now. Direct result: my AP is now interfering with 9 channels (4-12) instead of only 3 (11-13, see a few posts above). Now I (my AP) disturbs a lot more other Wi-Fis compared to before when it was configured to behave social (allowing HT40 only when this is the only 2.4GHz Wi-Fi available and doing a fallback to HT20 as soon as other Wi-Fis nearby are detected):

 

Bildschirmfoto%202017-03-11%20um%2013.20

 

 

As expected nothing changed with NanoPi Air and Raspberry Pi (AP6212/BCM43438 Wi-Fi/BT is not HT40 capable for obvious reasons: Wi-Fi would badly interfere with BT functionality) and also as expected enforcing HT40 on the AP led to much lower performance since now the AP chose channel 6 which is way more utilized here than channel 13 used before. So enforcing a so called 'High speed WIFI mode' on the AP leads to low speed Wi-Fi on devices in reality. So far so 'great'.

 

With OrangePi Lite's RTL8189FTV I was able to make use of HT40. PHY data rate is now reported as 150Mbps instead of 65Mbps before ('Great! Twice as much!') so let's have a look what the difference is in reality (since it's still crappy single antenna 2.4GHz Wi-Fi without MIMO):

 

With HT40 enabled under ideal conditions (50cm away from AP, rather large antenna) I get ~54 Mbits/sec on average with iperf3 and the following ping roundtrip times: 1.752/10.919/899.372/81.537 ms (min/avg/max/mdev)

 

Responsibly allowing the AP to only use HT20 (and back at least utilized channel 13) using same setup I get ~43 Mbits/sec on average with iperf3 and the following ping roundtrip times: 1.483/7.695/646.101/58.739 ms (min/avg/max/mdev).

 

So by behaving antisocial and destroying everyone else's Wi-Fi performance around (interfering with 9 channels now) I get a laughable 'stream performance' increase of approx 25 percent (not 100% as doubling the PHY rate would suggest!) while decreasing latency by the same amount (as expected). So if my application depends on low latency I get worse performance than before by choosing 'wider' bandwidth.

 

All of the above is the reason responsible admins and AP firmwares don't allow HT40 in 2.4GHz any longer (or allow it only if no other Wi-Fi utilizing the same channels is around). Since 'responsibility' means accepting that Wi-Fi uses a shared medium everyone has to compete for. If people would stop to use wrong settings (HT40 or all the intermediate channels apart from 1/6/11 or 1/5/9/13) then in crowded areas Wi-Fi performance could double for all users. Wi-Fi performance seems to be more related to knowledge of AP owners and Wi-Fi users in general and social behaviour than 'drivers' or other stuff we (Armbian) could make a difference :(

 

Details:

 

HT40:

  Reveal hidden contents

 

HT20:

  Reveal hidden contents

 

Igor

Igor

Posted
Posted
  On 3/11/2017 at 12:03 PM, tkaiser said:

HT40 with 2.4GHz band in 2017? Seriously?

Expand  

 

On a close range and if you are the only one with better equipment on both sides ... why not? Consumer router + client with cheap wireless unlikely, probably impossible in residential areas.
 

Weeks ago I got Mikrotik's router with powerful (1000mW) 2.4 AP and can provide few real world testing once next week. I can only say that it works at almost full speed/signal in other router dead spots ... with lots of neighbours AP's around.

zador.blood.stained

zador.blood.stained

Posted
Posted

Hm. Laptop ~1m away from the router

HT20:

  Reveal hidden contents

Forced HT40:

  Reveal hidden contents

 

So it should be marked as "YMMV"

tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/11/2017 at 2:36 PM, zador.blood.stained said:

So it should be marked as "YMMV"

Expand  

 

Hmm... if it's 20.1 Mbits/sec with HT20 and 67.4 Mbits/sec with HT40 then obviously something else is different too (since otherwise HT40 is not able to double HT20 throughput numbers and especially not able to increase it by 3.35 times as in your example). So it's about channel settings that obviously differed (that's the reason I always also collect 'iwconfig' and 'nmcli dev wifi list' output since this reveals sometimes the real reasons why performance differs).

 

Instead of 'YMMV' we should still try to collect more information here to be able to start with an Armbian Wi-Fi FAQ collecting some general Wi-Fi resources but also SBC specific (eg. lack of TX power).

 

I tried to repeat my 'location 4' tests (11m away from AP) with RTL8189FTV (HT40 capable, 1T1R antenna) and the MIMO capable RTL8192CU USB dongle (also HT40 capable but 2T2R antenna). With HT40 enabled my AP switches from 13 (good channel) to 6 (pretty bad channel here) and results with HT40 get really horrible due to 2 other AP close to 'location 4' sitting on channel 6 with high TX power:

 

HT40 and channel 6:

OPi Lite: Bit Rate:150 Mb/s, Sensitivity:0/0, Link Quality=36/100, Signal level=68/100, Noise level=0/100, 1.20 Mbits/sec on average

TL-WN823N: Bit Rate:300 Mb/s, Sensitivity:0/0, Link Quality=50/100, Signal level=-83 dBm, Noise level=0 dBm, 280 Kbits/sec on average

 

That's how 'nmcli dev wifi list' looked like:

  Reveal hidden contents

 

HT20 and back at channel 13:

OPi Lite: Bit Rate:65 Mb/s, Sensitivity:0/0, Link Quality=54/100, Signal level=69/100, Noise level=0/100, 11.6 Mbits/sec on average

TL-WN823N: Bit Rate:130 Mb/s, Sensitivity:0/0, Link Quality=98/100, Signal level=-67 dBm, Noise level=0 dBm, 12.4 Mbits/sec on average

 

Now 'nmcli dev wifi list' looked like:

  Reveal hidden contents

 

To sum it up: My own AP was listed with same signal strength in both attempts (52 out of 100) but due to different channels performance either totally sucked (extreme example the small MIMO USB dongle with just 280 Kbits/sec (!) on average) or looked ok-ish (either 11.6 Mbits/sec with 1T1R but huge antenna or 12.4 Mbits/sec with crappy antenna but 2T2R MIMO).

 

So it's still that users have to learn how heavily environment matters. In my totally overcrowded area enabling so called 'high speed' modes totally ruins performance since way too much other AP sit on the same channels then). MIMO and antenna diversity can greatly improve performance even if antenna is crappy (see picture below) and in case of larger distances the type and position/orientation of the antenna matters even more.

 

  On 3/11/2017 at 1:51 PM, Igor said:

Weeks ago I got Mikrotik's router with powerful (1000mW) 2.4 AP

Expand  

 

Well, high TX power might improve transfer speeds from AP to device but not the other way around (something I had to realize already but it would've been too much of a waste of time to drop all of the above numbers since 'average TX/RX numbers' don't reflect TX power settings accordingly. So that's on the TODO for another set of example throughput numbers with a device where I can easily adjust TX power).

 

BTW: Over larger distances the small MIMO capable dongle shows best results when operated horizontally (makes sense) with antenna directed towards AP. But based on dimensions of the dongle it is obvious that any large external antenna will outperform the stick regarding both TX and RX performance. With my setup it looks like this:

Antenna_comparison.jpg

@lex

@lex

Posted
Posted

NanoPi A64 has RealTek 8189ETV so i have ported it to 3.10.104 to see how it would performs on the A64 arena.

For the same distance, same antenna, no walls between i got the values below:

 

  • bpi-m64 AP6212 with BT enabled:  ~14 Mbits/sec
  • nanopi a64 with RTL8189es:  ~16 Mbits/sec

 

Unfortunately i don't have Wifi on my Pin64+ to compare with, but i realized it is very hard to get the same values (average values)  in different time of the day, for instance you get lower values during night.

 

RTL8189ETV seems to have better signal strength and better performance ( ~ 15% faster ) however i have had a hard time to authenticate with some of my wifi router.

 

m64-wifi.png

nanopi-a64-wifi.png

1
tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/19/2017 at 10:11 PM, @lex said:
  • bpi-m64 AP6212 with BT enabled:  ~14 Mbits/sec
  • nanopi a64 with RTL8189es:  ~16 Mbits/sec
Expand  

 

Well, adding to your experiences (environment matters, eg. time of the day, you're never alone when using Wi-Fi) three things should be added:

  • 14 vs. 16 Mbits/sec is a difference of less than 15 percent so close to 'result variation' (especially when having in mind that the maximum with this implementation (2.4GHz/HT20) is around 45 Mbits/sec --> 2 Mbits/sec difference with 45 Mbits/sec max is not even 5 percent, so maybe it would be an idea to test again with 1m distance between board and AP?)
  • It seems you only tested from board to another host but not the other way around? If so I wonder whether different TX power settings make any difference (though no idea how to influence/test this, just based on a comment from Jon Smirl on CNX)
  • I would prefer to always get the output of 'iwconfig' too since some differences in performance/observations may be easy to understand by numbers/settings listed there (eg. with powermanagement active throughput might vary a lot and end result might look lower even if specific implementation would be faster) 

 

@lex

@lex

Posted
Posted (edited)

The results for nanoPi A64 - RTL8189es, 1 meter away,  just the monitor between board and the wireless router/modem. tested against my ultra dual core pentium:):

*Update: no ehternet tune script this time!

 

iwconfig:

  Reveal hidden contents

From the board:

  Reveal hidden contents

 

The other direction:

  Reveal hidden contents

 

Edited by @lex
spoiler
1
@lex

@lex

Posted
Posted (edited)

Results for bpi-m64, same condition:

 

iwconfig:

  Reveal hidden contents

From the board:

  Reveal hidden contents

 

Other direction:

  Reveal hidden contents

 

Edited by @lex
spoiler
tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/20/2017 at 1:00 PM, @lex said:

Results for bpi-m64, same condition

Expand  

Hmm... really? Thanks for the iwconfig output since I was looking for this: 

root@nanopiair:~# iwconfig wlan0 power off
root@nanopiair:~# iwconfig wlan0 | grep 'Power Management'
          Power Management:off
root@nanopiair:~# iwconfig wlan0 power on
root@nanopiair:~# iwconfig wlan0 | grep 'Power Management'
          Power Managementmode:All packets received

 

@lex

@lex

Posted
Posted (edited)

With power management off: 

ubuntu@bpi-m64:~$ sudo iwconfig wlan0 power off

 

iwconfig:

  Reveal hidden contents

 

from board:

  Reveal hidden contents

 

other direction:

  Reveal hidden contents

 

Edited by @lex
spoiler
tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/9/2017 at 12:03 PM, tkaiser said:

testing 'location 4': 11m away from my AP in neighbour's flat with 3 walls and some chimneys in between.

Expand  

 

Since I ordered in the meantime this cheap dual-band/dual-antenna Wi-Fi dongle (based on Ralink RT5572, 802.11n capable, rt2800 driver in mainline kernel) I just gave it a try again and tested from location 4 only (description and results with the onboard variants see above):

 

I tested with a board using kernel 4.9 so getting Wi-Fi up and running was just the usual 'nmtui-connect' call and I were in. Please take the 2.4GHz results with a grain of salt since I don't wanted to wait until midnight for tests and Wi-Fi testing in a city in 2.4 GHz band on a saturday afternoon is almost stupid (since neighbours dictate your performance more than anything else). Test setup is as before, there's a GBit Ethernet connected machine running 'iperf3 -s' and I test from the board both directions with 'iperf3 -c 192.168.83.146 -t 120 && iperf3 -R -c 192.168.83.146 -t 120'. So there's always two values, the first one is the 'board to other device' number and the 2nd the opposite.

 

2.4 GHz: 8.21 Mbits/sec / 8.52 Mbits/sec

  Reveal hidden contents

5 GHz: 3.95 Mbits/sec / 18.4 Mbits/sec

  Reveal hidden contents

As already said results in 2.4GHz band are questionable since saturday afternoon and 5GHz results not that overwhelming when comparing with the little cheaper 2T2R RTL8192CU dongle above (2.4 GHz).

 

Since I ordered a 2nd Wi-Fi dongle that came with much larger antennas I shut the board down, replaced antennas and repeated the same test with exactly same software/setup. So from here on only antennas matter:

 

2.4 GHz: 5.65 Mbits/sec / 8.26 Mbits/sec

  Reveal hidden contents

5 GHz: 7.61 Mbits/sec / 36.7 Mbits/sec

  Reveal hidden contents

In 5 GHz band the huge antennas led to a nice improvement (almost twice the numbers) so it seems that's always worth a test.

 

Size_Comparison.jpg

@lex

@lex

Posted
Posted

Waiting for the IPX RF cable to arrive and see how it will boost the signal, 12dBi Omni wifi antenna, $6.75 (now $7.50) on AliExpress. Will try to reproduce same test and post here.12db.thumb.jpg.2d5c0b174ba9b76d13836e191544b183.jpg

 

 

1
  • Igor unpinned this topic
@lex

@lex

Posted
Posted (edited)

Output: with another round of iperf3, 3M from AP, just some equipment turned on around. Small antenna 

 

* added info screen 

ubuntu@nanopi-a64:~/iperf/iperf/src$ iw wlan0 info
Interface wlan0
    ifindex 9
    wdev 0x1
    addr 34:c3:d2:13:f1:f0
    ssid foxy
    type managed
    wiphy 0
ubuntu@nanopi-a64:~/iperf/iperf/src$
ubuntu@nanopi-a64:~/iperf/iperf/src$ ./iperf3 -c 192.168.254.100
Connecting to host 192.168.254.100, port 5201
[  5] local 192.168.254.101 port 52448 connected to 192.168.254.100 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  5.82 MBytes  48.9 Mbits/sec    0    136 KBytes       
[  5]   1.00-2.00   sec  8.10 MBytes  68.0 Mbits/sec    0    335 KBytes       
[  5]   2.00-3.00   sec  10.9 MBytes  91.2 Mbits/sec    0    752 KBytes       
[  5]   3.00-4.00   sec  10.5 MBytes  87.9 Mbits/sec    0    919 KBytes       
[  5]   4.00-5.00   sec  10.4 MBytes  87.5 Mbits/sec    0   1.11 MBytes       
[  5]   5.00-6.00   sec  10.1 MBytes  84.4 Mbits/sec    0   1.14 MBytes       
[  5]   6.00-7.00   sec  10.5 MBytes  88.2 Mbits/sec    0   1.17 MBytes       
[  5]   7.00-8.00   sec  10.6 MBytes  88.9 Mbits/sec    0   1.17 MBytes       
[  5]   8.00-9.00   sec  11.2 MBytes  93.9 Mbits/sec    0   1.17 MBytes       
[  5]   9.00-10.00  sec  10.1 MBytes  84.4 Mbits/sec    0   1.17 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  98.2 MBytes  82.3 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  98.1 MBytes  82.3 Mbits/sec                  receiver

iperf Done.
ubuntu@nanopi-a64:~/iperf/iperf/src$ ./iperf3 -R -c 192.168.254.100
Connecting to host 192.168.254.100, port 5201
Reverse mode, remote host 192.168.254.100 is sending
[  5] local 192.168.254.101 port 52452 connected to 192.168.254.100 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  5.80 MBytes  48.7 Mbits/sec                  
[  5]   1.00-2.00   sec  6.38 MBytes  53.6 Mbits/sec                  
[  5]   2.00-3.00   sec  6.75 MBytes  56.6 Mbits/sec                  
[  5]   3.00-4.00   sec  7.04 MBytes  59.0 Mbits/sec                  
[  5]   4.00-5.00   sec  7.05 MBytes  59.1 Mbits/sec                  
[  5]   5.00-6.00   sec  6.74 MBytes  56.5 Mbits/sec                  
[  5]   6.00-7.00   sec  6.68 MBytes  56.0 Mbits/sec                  
[  5]   7.00-8.00   sec  7.08 MBytes  59.4 Mbits/sec                  
[  5]   8.00-9.00   sec  7.34 MBytes  61.6 Mbits/sec                  
[  5]   9.00-10.00  sec  7.26 MBytes  60.9 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  69.0 MBytes  57.9 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  68.1 MBytes  57.1 Mbits/sec                  receiver

iperf Done.
ubuntu@nanopi-a64:~/iperf/iperf/src$ iwconfig
gre0      no wireless extensions.

lo        no wireless extensions.

wlan1     no wireless extensions.

ifb1      no wireless extensions.

wlan0     no wireless extensions.

ifb0      no wireless extensions.

bond0     no wireless extensions.

tunl0     no wireless extensions.

gretap0   no wireless extensions.

eth0      no wireless extensions.

ubuntu@nanopi-a64:~/iperf/iperf/src$ ifconfig
eth0      Link encap:Ethernet  HWaddr 36:c9:e3:f1:b8:05  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:172 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:172 errors:0 dropped:0 overruns:0 frame:0
          TX packets:172 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:12678 (12.6 KB)  TX bytes:12678 (12.6 KB)

wlan0     Link encap:Ethernet  HWaddr 34:c3:d2:13:f1:f0  
          inet addr:192.168.254.101  Bcast:192.168.255.255  Mask:255.255.0.0
          inet6 addr: fe80::9038:9be2:fbab:3b4b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:219375 errors:0 dropped:1678 overruns:0 frame:0
          TX packets:217636 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:235441182 (235.4 MB)  TX bytes:228918541 (228.9 MB)

wlan1     Link encap:Ethernet  HWaddr 36:c3:d2:13:f1:f0  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:45 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ubuntu@nanopi-a64:~/iperf/iperf/src$ 

 

wifi2.png

Edited by @lex
rtl8189es info
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept