300mbps SQM on MT7621DAT as dumb AP

[moeller0]

@CrackedPotato

This one is with no pinging, on wired

https://www.waveform.com/tools/bufferbloat?test-id=2b3d78bf-a46a-4fc2-b3e9-86123fb687e5

This looks reasonable. Which browser did you use? There is a consistent second band of latency around 47ms visible in all three load conditions which might not actually reflect network latency, but might be an artefact of your browser... (I see similar things when using safari, which go away when I use firefox or chrome, maybe this is a similar issue?)...

@CrackedPotato

Laptop oon wifi pinging rpi4 while test runs on ethernet

https://www.waveform.com/tools/bufferbloat?test-id=375150cc-3150-45a6-a032-763f44e3e591

This test reveals something odd, the upload rate completely tanked, 9 Mbps out of expected 280-290? I would not trust that test....

@brada4

Only thing I see is 50 and 150ms being some QoS activation threshold, in openwrt those will be 5ms or 20ms

Or some application level delay, say garbage collection intervals in the browser... modern browsers are excellent swiss army knives with loads of utlity for a lot of use cases, but being a high quality, high temporal precision measurement environment is not one of them... This is why I tend to not take them as gold standard, but a really convenient quick and dirty tool to start looking into things...

@CrackedPotato

I meant, QOS activating at 5 and 20 is much better than 50,150?

So ISPs typically have a single queue for each subscriber and that will generate a single latency bound (once the queue is full excess incoming packets are dropped immediately) so I am not sure that the two latency bands you see in your tests actually reflect your ISP's queues veridically.

[CrackedPotato]

@moeller0

Which browser did you use?

Brave.

I read safari is icky with testing.

[moeller0]

Please try firefox and chrome/chromium just to rule out a simple browser effect...

[eginnc]

@moeller0

This test reveals something odd, the upload rate completely tanked, 9 Mbps out of expected 280-290? I would not trust that test....

It's definitely odd. I too found it odd.

I can confirm I experienced same with fq_codel/simple when using my ER-X as a gateway with DOCSIS 500/20 ISP service (570/23 on a good day). Download (CPU limited) topped out around 200 Mbps, but upload at only around 10 Mbps using fq_codel/simple. CAKE delivered around 100 to 150 download (150 was before DSA conversion slowed things down) and around 20 upload, as expected.

[moeller0]

@eginnc

It's definitely odd. I too found it odd.

Especially since the latency increase was reported as only +4ms....

[CrackedPotato]

Going off your figures, I think the router could do 50-100 more plus the 200 on fq codel as a dumb AP, fair assumption?

[CrackedPotato]

Brave

Bufferbloat Test Result: A

Bufferbloat Test Result: A

Chromium

Bufferbloat Test Result: A

Bufferbloat Test Result: B

Bufferbloat Test Result: A

This is night time, so not a lot of stuff going on, plus less devices online.

[brada4]

Something 50ms gets added, which is unlikely with OpenWRT

[CrackedPotato]

Got it.

Is there any way for me to check if the stock firmware uses TXQs and AQL? I enabled airtime fairness.

[brada4]

Only reverse-engineering OEM firmware (in short - not really)

[moeller0]

@CrackedPotato

Is there any way for me to check if the stock firmware uses TXQs and AQL? I enabled airtime fairness.

Well, try to run the commands I cited above, with luck the vendor formware should at least support the iw command:

iw list | grep 'Wiphy\|TXQS\|AIRTIME_FAIRNESS\|AQL'

But really all bets are off with vendor firmwares and you are on your own.

That said if you truly have latency sensitive traffic do NOT connect such devices via WiFi, run a cable...

[moeller0]

But you have ssh access to the vendor firmware, so why do you not try yourself?

[CrackedPotato]

I do not. Stock firmware doesn't seem to allow it.

Looking at the extracted squashfs root, there is no iw binary, only iwinfo,iwpriv,iwconfig,iwlist

[romanovj]

stock is using proprietary mtk driver, so no "iw" binary

[amteza]

@CrackedPotato, the link you are referring to is utilising a NanoHD (mt7621), not a TP-Link and it is not close 450 Mbps speeds in the graph. In any case the main differences to your router are:

1. OpenWrt installed in the dump AP.
2. aql_txq_limit = 1500 (ms) in the 5 GHz interface.
3. Patches lowering target and interval to 8 ms and 80 ms in the driver.

I don't think is a fair comparison. In any case, just increasing aql_txq_limit it increases bandwidth to 420 Mbps and increases latency under load to close to 20 ms.

Honestly, your best bet is just installing OpenWrt in your AX23, full stop.

[brada4]

Since revert is confirmed working

Tp-link AX23 wrong firmware version number after reverting

Thanks for testing! You should watch out with echo though, as by default it will append a newline to your output. Use echo -n or printf if you want more precise control. The count argument for dd is also not required if you want to use all input: printf "1.1.0" | dd of=mtd6_dump.bin seek=198673 bs=1 conv=notrunc The above will only replace the 5 bytes providing the version number (if the offset for seek= is correct).

no point in debugging OEM defects any further.

[CrackedPotato]

On openwrt now, with hardware offload enabled I can't even reach 100 Mbps over wifi now..

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'
config globals 'globals'
        option ula_prefix 'fdc2:b207:2428::/48'
        option packet_steering '1'
config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.0.2'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '192.168.0.1'
        option delegate '0'
        list dns '192.168.0.1'
        list dns '8.8.8.8'

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option band '2g'
        option htmode 'HE20'
        option cell_density '0'
        option channel 'auto'
        option country 'IN'
config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'TP-Link_F5B2'
        option encryption 'sae-mixed'
        option key 'r'
config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
        option channel '36'
        option band '5g'
        option htmode 'HE80'
        option cell_density '0'
config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'TP-Link_F5B2_5Ghz'
        option encryption 'sae-mixed'
        option key 'r'

[brada4]

Why would you ever need hardware offload? Your device can move gigabit (ok, maybe 899Mbps) with its CPU.

Some deficiencies (maybe you did not post)
In /etc/config/dhcp there should be a section

config dhcp 'lan'
  option interface 'lan'
  option ignore '1'

And you need country code in 5GHz radio too. Especially in India that will unlock whole 5ghz band at double power.

Offload plays no role in Dumb-AP scenario.

EDIT: then re-test with waveform.

[CrackedPotato]

Yep, DHCP is already set like that.

Set country code to IN.

Since I was getting below 100, I tried enabling offloading.

Still sitting about 80mbps

Edit - the bufferbloat is ATROCIUS!

Bufferbloat Test Result: D

[brada4]

What happens with waveform if you connect client via AX23 bridge, i.e other LAN port than one linked to internet?