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?
Just for clarity, I see same behaviour on these two scenarios:
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):
@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? 
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.
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.
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)
@ka2017 on your "bad" station. There is exactly a 10s period on both the nup and ndown plots.
Is awd off? (I loathe this apple "feature")
Is upnpd on or off?
Are you running the post-multicast fix that went in?
This kind of behavior is also reminiscent of a rate controller at the edge of its range, but...
PS it helps me if you label with the -t what_was_under_test. I'm assuming that this first plot in the series was taken in close range? You can still see (small) signs of a periodic spike here too, but it is otherwise pretty good.
Yes, Airdrop and AWDL are disabled using WiFriedX https://medium.com/@mariociabarra/wifriedx-in-depth-look-at-yosemite-wifi-and-awdl-airdrop-41a93eb22e48 .
No, I do not have miniupnpd or any other UPNP related packages installed in the router/AP.
No, I am running the 22.03.0-rc5 release which was tagged on July 6, 2022.
The multicast fix commit was added just few hours back in both master and 22.03 branch.
BBR oscillates on a 10s interval... any chance you are using bbr?
Are there other awdl enabled devices nearby? I've actually never measured the impacts on wifi performance on it, using these tools. It would be good to capture and visualize the real world effects in a situation where we knew it was enabled.
mdns (e.g an apple tv) does multicast periodically. so do all apple devices. Please give the multicast commit a shot, at this bad range, just the nup/down tests would be great.
