WiFi performance with mac80211 driver vs Ralink

Nick Garner

Any updates on this new driver? We need to do a custom build and the wifi is killing us. I'd hate to have to ship a wired ethernet only product.

Nick

shoresup

I have noticed the performance drop on the wifi also. Running a custom OpenWrt build (19.07) but the wifi is quite a bit slower on the custom build vs the original 18.06 based firmware. Have any solutions been developed in the mean time?

Would the new 23.05 based OpenWrt build offer better wifi speeds?

crispyoz

@shoresup better not to necro-post, new post is better with a reference to an old post. Anyway, 18.06 used an Onion developed Wifi driver, which is not available in later versions.

OpenWrt 19 was really a transitional version so I don't have much experience with that version however Wifi performance may be configuration related rather than specific to the driver. Please share your wifi configuration ( /etc/config/wireless ) also the output of the command:

iwinfo radio0 scan

shoresup

Hi,

Apologies for 'necro-posting'. I have learned a new term...

This is the /etc/config/wireless:

config wifi-device 'radio0'
option type 'mac80211'
option variant 'mt7628'
option country 'US'
option hwmode '11g'
option htmode 'HT20'
option channel 'auto'
option disabled '0'
option device_mode 'apsta'
option op_mode 'preference'
option path 'platform/10300000.wmac'

config wifi-iface 'ap'
option device 'radio0'
option mode 'ap'
option ifname 'ap1'
option encryption 'none'
option network 'wlan'
option disabled '0'
option ssid 's2snode_4ae8'

config wifi-iface 'mesh0'
option network 'meshlan'
option ifname 'mesh0'
option device 'radio0'
option mode 'mesh'
option mesh_fwding '1'
option mesh_id 'shore2ship'
option log_level '0'
option mesh_rssi_threshold '0'
option encryption 'sae'
option disabled '1'

config wifi-iface 'sta'
option device 'radio0'
option mode 'sta'
option ifname 'apcli0'
option encryption 'psk2'
option network 'wwan'
option disabled '0'
option ssid 'smurfenland'

And this is the result of iwinfo radio0 scan

Cell 01 - Address: 34:60:F9:63:65:9C
ESSID: "smurfenland"
Mode: Master Channel: 6
Signal: -35 dBm Quality: 70/70
Encryption: WPA2 PSK (CCMP)

Cell 02 - Address: 3A:60:F9:63:65:9C
ESSID: unknown
Mode: Master Channel: 6
Signal: -35 dBm Quality: 70/70
Encryption: WPA2 PSK (TKIP, CCMP)

Cell 03 - Address: 3E:60:F9:63:65:9C
ESSID: unknown
Mode: Master Channel: 6
Signal: -35 dBm Quality: 70/70
Encryption: WPA2 PSK (CCMP)

Cell 04 - Address: 42:60:F9:63:65:9C
ESSID: unknown
Mode: Master Channel: 6
Signal: -35 dBm Quality: 70/70
Encryption: WPA2 PSK (CCMP)

Cell 05 - Address: 22:EB:B6:A6:A0:0A
ESSID: unknown
Mode: Master Channel: 11
Signal: -68 dBm Quality: 42/70
Encryption: mixed WPA2/WPA3 PSK/SAE (CCMP)

Cell 06 - Address: 1E:EB:B6:A6:A0:0A
ESSID: unknown
Mode: Master Channel: 11
Signal: -68 dBm Quality: 42/70
Encryption: mixed WPA2/WPA3 PSK/SAE (CCMP)

Cell 07 - Address: 14:EB:B6:A6:A0:0A
ESSID: "smurfenland"
Mode: Master Channel: 11
Signal: -68 dBm Quality: 42/70
Encryption: WPA2 PSK (CCMP)

Cell 08 - Address: 1A:EB:B6:A6:A0:0A
ESSID: unknown
Mode: Master Channel: 11
Signal: -69 dBm Quality: 41/70
Encryption: WPA2 PSK (TKIP, CCMP)

crispyoz

@shoresup Have you used iperf to measure your actual performance? What rate are achieving?

If you are not in the US change your country option to match your actual country. I'm in Oz and if I leave my Omega2+ set to US, performance seems to fluctuate. The cause is the difference in wifi frequencies between the AP and the Omega2+, since hardware available here in Oz adheres to the Aussie regulations which are different to the US regulations.

If you run iperf and record the results then update your device to openwrt 23 Beta release available here you can easily do a performance comparison.

shoresup

Hi,

Many thanks for pointing me in the right direction. The 'US' setting did not make a difference.

Using iperf showed consistent results of approx 50 Mbps which is inline what iw station dump shows as theoretical throughput. This was the same on 18.06 versus 19.07 versus 23.05, so it looks as though the wifi link is not the problem!

Testing with various file transfer tools like rsync and scp however showed quite big differences. On the 18.06 and 23.05 both rsync and scp are showing approx 1.5 MB/sec throughput and on 19.07 it is about half. Which makes me think the bottleneck is in the filesystem rather than the transmission link.

Still wondering however where things can be improved. 1.5 MB/sec works out at approx 12 Mbps which is still far from the theoretical throughput of 50 Mbps. Our application is all about file transfer, so looking to optimise the performance in that area.

crispyoz

@shoresup you can isolate the file system as a performance bottleneck by running a test using dd. I create one file name myread containing:

#!/bin/sh

dd if=/dev/zero of=myfile bs=8k count=10000
sync

and another named mywrite containing:

#!/bin/sh

dd of=/dev/zero if=myfile bs=8k count=10000
sync

Now run these commands to see their timings:

time -v sh myread
time -v sh mywrite

This will give you the file system timings for reading and writing 10000 blocks to and fro the file system

There are other tools but I like dd because it's a really basic test

shoresup

@crispyoz these are the results:

root@Omega-72D9:~/scripts# time -v sh myread
10000+0 records in
10000+0 records out
Command being timed: "sh myread"
User time (seconds): 0.18
System time (seconds): 439.25
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 7m 22.56s
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 4432
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 149
Voluntary context switches: 5
Involuntary context switches: 465526
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
root@Omega-72D9:~/scripts# time -v sh mywrite
10000+0 records in
10000+0 records out
Command being timed: "sh mywrite"
User time (seconds): 0.07
System time (seconds): 4.36
Percent of CPU this job got: 89%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 4.92s
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 4368
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 154
Voluntary context switches: 5
Involuntary context switches: 40108
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

shoresup

On the 19.07 firmware, I noticed both read and write took about twice as long:

10000+0 records in
10000+0 records out
Command being timed: "sh myread"
User time (seconds): 0.06
System time (seconds): 409.89
Percent of CPU this job got: 44%

But then I noticed the CPU percentage assigned to this job. After some further investigation realised this was due to a python script which was running on this firmware and narrowed it down to a specific piece of code which was misbehaving. After modification, we are now getting the same transfer speeds on the 19.07 firmware. So no problem with the wifi drivers or filesystem, just a bad piece of code..... ;-(

Again thanks for pointing me in the right direction.

Still wondering about the difference between the theoretical throughput (50 Mbps) vs actual (12 Mbps). I guess most of that is (lack of) cpu performance then....

crispyoz

@shoresup Glad you got that sorted, sometimes it just needs a second pair of eyes. We've all been there.

Iperf is testing the max performance through the device, but file transfer utilities have several overheads, so for example if I use sftp, we have several steps:

read data chunk
encrypt data
transmit data
wait for ack
repeat

sftp (for example) packet size can impact on performance, depending on your network driver (either wifi/ethernet et al), you may get better performance by tweaking -B parameter on sftp.

A simple test I use if ftp, because it removes the overhead of encryption/encoding of sftp. Actually I often use zmodem or modem for my test, maybe because I'm old