DSCP seems to affect WiFi download speeds

I have a Windows 10 laptop with an Intel AC 9560 WiFi card and immediately upon (re)connection to 2.4Ghz I can download and upload at an acceptable ~110Mbit. After some time, I am limited to ~25Mbit download from all servers; wired, wireless, local, or remote. Upload speed stays consistent. This download inconsistency didn't exist with my old Asus RT-N66U, only my new GL.iNet GL-MT6000 with OpenWrt 23.05.3.

The strange thing is that when I change iperf3's DSCP to 1, 21, 24, 32, 40, or a few others, the download jumps back to ~110Mbit. DSCP 48 and 56 gives me 50Mbit. DSCP 0, 8, and 16 gives me 25Mbit. These results are consistent across many dozens of iperf3 tests and other local and remote speedtests.

My WiFi network is practically unused during these tests.

I had no idea that DSCP could have this type of affect on an uncongested WiFi network. Any help is appreciated. I'm kinda lost at this point...

Could be WiFI WMM related. Here is my understanding of OpenWrt's DSCP to UP to AC mapping:

+       set_default iw_qos_map_set 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56

Which translates into the following mappings (according to the hostapd rules below*):

unraveling this gets us to (0 is coded as DSCP Exception, the rest as DSCP ranges):

UP	    DSCP	AC	  PHBs(decDSCP)
Ex0	    BE	    BE(0) BE/CS0(0)
Range0	2-16	BE	  CS1(8), AF11(10), AF12(12), AF13(14), CS2(16)
Range1	1-1	    BK    LE(1)
Range2	-	
Range3	18-22	BE	  AF21(18), AF22(20), AF23(22)
Range4	24-38	VI	  CS3(24), AF31(26), AF32(28), AF33(30), CS4(32), AF41(34), AF42(36), AF43(38)
Range5	40-40	VI	  CS5(40)
Range6	44-46	VO	  VA(44), EF(46)
Range7	48-56	VO	  CS6(48), CS7(56)

But that does not map nicely to your reported numbers...


VOice class dismantles MPDU and has less speed and minimal latency.
VIdeo class sends out half MPDU if there is no full BE MPDU
BestEffort class works normally
BulK class buffers to full MPDU and always is queued last after others are sent.

They are mapped to tc subqueues, normall the default priorities work well, but you might want smth like codel for one class if for example you have 10 clients with video conference.

1 Like

iperf3 -R --dscp results:

Range0: BE 25Mbit
Range1: BK 100Mbit
Range2: -
Range3: BE 100Mbit
Range4: VI 100Mbit
Range5: VI 100Mbit
Range6: VO 50Mbit
Range7: VO 50Mbit

Yeah, DSCP 0 and Range0 both being BE at 25Mbit, while Range3 is also BE but at 100Mbit doesn't quite match up.

But you measure UPLOAD with -R and priority queues in windows

I'm running the iperf3 client on Windows with -R (reverse mode), which causes the iperf3 server on my LAN to transmit the data, making the Windows client the downloader.

C:\iperf3.16_64>iperf3.exe -c -R --dscp 18
Connecting to host, port 5201
Reverse mode, remote host is sending

Disable windows QoS, once it encounters high priority class it reserves bw for it forever.

1 Like

All of my WiFi clients (Linux, Android, Windows) show a massive decrease (~75%) in WiFi download throughput when setting DSCP 48-56. Is this expected?

I assumed that unless there's congestion, there was no artificial upper-limit on throughput when QoS/traffic-shaping is used.

It is totally expected. VOice class does not aggregate frames (Protocol Data Units) into mega-frames (Multi-PDU)

See here: https://evenroute.com/internet-speed

1 Like

WiFi has a massive overhead per each transmit opportunity. It tries to ameliorate this by aggregating multiple ip packets into the same transmit to spread tje overhead over more data bytes, but the two higher priority tiers are limited stronger in the amount of aggregation allowed to ballance their higher probabilty to get airtime slots somewhat.
That might be part of your issue, but IMHO the mapping of dscps to throughput looks somewhat odd. Maybe it is time for packet captures and see which dscps actually are set...

1 Like

25Mbit for voice is in the range of 1000 concurrent calls, If you are carrier of that scale i'd bet you can afford a cable or two.

Packet captures at both the sender and receiver show DSCP correctly, as set from iperf3.

I haven't experienced any problems with 5Ghz, where all my important, bandwidth heavy, devices connect. I run iperf3 tests every day from my Galaxy S10+ phone and always see 800/500Mbit results with default DSCP.

It seems like DSCP 0 and "Range0" (dscp 8-16) are being categorized incorrectly? and maybe only 2.4Ghz is affected?

I disabled Windows' "QoS Packet Scheduler" on the wifi adapter like @brada4 advised, but the 25Mbit download problem popped back up after 10 minutes or so after reconnecting.

1 Like