Click on your wireless status bar icon while pressing Option key.
Any idea how to do this over VNC with Windows QWERTY Keyboard?
Sure, press Alt key if it is Windows logo keyboard.
1 Like
Yes, so the problem is happening on your WiFi link. I would even say macosx is likely not the culprit, since it does not drive the WiFi directly. That gets us to:
NanoHD --4x4 MIMO WiFi connection--> NanoHD
What if you switch the nanoHD's things likely stay the same?
What if you change the direction from which you start the test things likely stay the same as well?
1 Like
Just for clarity, I see same behaviour on these two scenarios:
- Macbook Pro ---WiFi 2x2 MIMO---> NanoHD ---Ethernet---> Router
- Macbook Pro ---Ethernet---> NanoHD ---WiFi 4x4 MIMO---> NanoHD ---Ethernet---> Router
Note: Will do a test in a couple of hours with connectivity chain no. 2.
Update: Here it goes ("same" results than when connected to the main AP directly):
Click me to donwload flent data
1 Like
@dtaht I ran
Flent tests:
rrul_be,
tcp_ndown (4 streams),
tcp_nup (4 streams)
Servers:
Local (Netperf and irtt running in Router/AP),
Remote (mumbai.starlink.taht.net)
Router/AP: Belkin RT3200 running OpenWrt 22.03.0-rc5
ISP: Airtel India, GPON Fiber, PPPoE, 40/40 Mbps Plan, IPv4 + IPv6
Location: (near) Chennai, Tamil Nadu, India
SQM on WAN: CAKE + layer_cake.qos, Download 42500, Upload 47500, Ingress options "ingress besteffort nat dual-dsthost", Egress options "egress diffserv4 nat dual-srchost", Ethernet with Overhead, Per Packet Overhead 44 bytes
WIFI Settings:
5 GHz, Channel 36, VHT20, TX Power 27 dBm, WPA2-PSK AES, 802.11w disabled, Beacon Interval 100, DTIM Interval 5
2.4 GHz, Channel 11, HT20, TX Power 20 dBm, WPA2-PSK AES, 802.11w disabled, Beacon Interval 100, DTIM Interval 5
Client: 2017 Macbook Air (Intel x86_64)
OS: macOS 12.4 Monterey
WiFi Card: Broadcom BCM43xx
Client in different room from Router/AP, with Brick wall between them.
Tested over SSH.
VNC not connected during tests.
Client RSSI measured in Router/AP:
2.4 GHz: -66 dBm (Noise -91 dBm)
5 GHz: -84 dBm (no noise info)
Router RSSI measured in Client:
2.4 GHz: -66 dBm (Noise -89 dBm)
5 GHz: -71 dBm (Noise -101 dBm)
Flent data files, log files and output images (only for rrul_be tests) at https://www.dropbox.com/sh/yuoy84klujqs9ld/AAAFAYebsQfArJT7MRPoe-GLa?dl=0
In case it helps, if you can ssh in to the macbook or just bring up a terminal then use airport -I
nmba [1] $ airport -I
agrCtlRSSI: -72
agrExtRSSI: 0
agrCtlNoise: -87
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 175
maxRate: 144
lastAssocStatus: 0
802.11 auth: open
link auth: unknown
BSSID:
SSID:
MCS: 5
guardInterval: 800
NSS: 1
channel: 36,80
Ref: AQL and the ath10k is *lovely* - #737 by ka2107
% /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
agrCtlRSSI: -71
agrExtRSSI: 0
agrCtlNoise: -99
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 39
maxRate: 144
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2-psk
BSSID:
SSID: XXXX_5GHz
MCS: 4
guardInterval: 800
NSS: 1
channel: 36
% /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
agrCtlRSSI: -62
agrExtRSSI: 0
agrCtlNoise: -87
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 117
maxRate: 144
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2-psk
BSSID:
SSID: XXXX_2.4GHz
MCS: 14
guardInterval: 800
NSS: 2
channel: 11
I had no idea the airport tool existed. Thx!
With Linux "minstrel" wifi rate control, polling the equivalent iw stat would jump around during a test somewhat.
No idea how osx does rate control. Really remarkable how it is so solid on osx during these tests. Perhaps during a test
for i in `seq 1 60`
do
airport -I | grep lastTxRate
sleep 1
done > ratecontrol.txt
lastTxRate: 866
lastTxRate: 866
[...]
lastTxRate: 866
lastTxRate: 866
No variation, 60 lines with a nice 866 as TX rate.
@dtaht Not sure if you missed my post due to so many posts in this thread, but the results are at AQL and the ath10k is *lovely* - #737 by ka2107
I didn't miss it, I gave into despair.
temporarily. As much as I love data, consider me drowned. Can't we keep a warm mellow glow on for it not crashing for a few days more? 
1 Like
Does this mean the airtime fairness project is not working and should be scrapped (at least pending further development)?
Will the problems you have helped expose reflect typical use case? Or is this just an isolated problem case?
We were aiming for stability first, which we now have, and are also demonstrating good multistation performance, which implies that fq, atf, and codel are working.
The down/up disparity thing on osx is different from ATF. We try to be ATF across stations, we don't try to enforce up/down fairness within a station, but my expectation was that it would naturally be half.
@ka2107 's test of a purposely bad station ... I need to look over the nup and down.
So it's not that this airtime fairness concept is a kind of fancy pants approach that ends up being a bit Heath Robinson whereas the round robin concept is nice as simple as just works most of the time?
I mean the airtime fairness is technically justifiable and reasonable, and a good springboard for further development?
Is it not slightly scary the length of time taken with this improved approach in terms of releases to just to try to get something close to original performance?
Hope my cheeky questions don't ruffle too many feathers.
given the structure of the code about 40ms latency is to be expected on this test. Yes, it's "meh" but its the best that has ever been done in open source wifi.
I think you are misunderstanding something. The virtual scheduler and round robin scheduler both attempt to be air time fair. Actually seeing a benefit from the v scheduler is on my mind, but there were 9 other bugs to solve first, like not crashing.
1 Like
Sorry, I thought you missed it since you replied to my latter post ("airport -I" output) but not the post with the results.
OK but I think my cheeky comments still apply? If I understand correctly the virtual approach has caused many problems and introduces a lot of complexity whereas the round robin approach worked pretty well? Or not?
It's perhaps not comparable but on the CAKE autorate project one or two rate control approaches went down the route of lots of fancy pants Heath Robinson like complexity and didn't work for many use cases. Whereas a very simple approach originally conceived by @moeller0 provided a great foundation for something that just more or less worked. It seems like it's ever so easy to add complexity to try to improve but it ends up getting messy and Heath Robinson?
Like you can have a system involving only a few simple rules for rate control vs a bayesian statistical model and much additional complexity, only to find the complicated model has a hard time beating the simple system.
I am just curious if the same issue could apply here. Perhaps my comments don't apply here for one reason or another. Apologies if so.
1 Like
Ref: AQL and the ath10k is *lovely* - #737 by ka2107
2.4 GHz
% networkQuality -v
==== SUMMARY ====
Upload capacity: 25.530 Mbps
Download capacity: 9.767 Mbps
Upload flows: 16
Download flows: 20
Responsiveness: Medium (367 RPM)
Base RTT: 44
Start: 14/Jul/2022, 03:36:15
End: 14/Jul/2022, 03:36:32
OS Version: Version 12.4 (Build 21F79)
5 GHz
% networkQuality -v
==== SUMMARY ====
Upload capacity: 14.562 Mbps
Download capacity: 31.202 Mbps
Upload flows: 20
Download flows: 12
Responsiveness: Low (149 RPM)
Base RTT: 39
Start: 14/Jul/2022, 03:37:22
End: 14/Jul/2022, 03:37:38
OS Version: Version 12.4 (Build 21F79)