802.11n extremely slow on Archer C7

Installing and Using OpenWrt
#1

Hi, this is something that might be a bug, or maybe I'm missing something obvious?

I am using LEDE 17.01.4 on an Archer C7.

With the Generic MAC80211 802.11bgn radio on the 2.4 ghz band I experience the following:

Legacy mode, WMM off = Correct 802.11g speed, no issues, stable.
N mode, WMM off, channel width 20 = Same as 802.11g speed (expected, since WMM is required for N)
N mode, WMM ON, channel width 20 = Super SLOW speed, e.g. 1-2 Mbit on downloads.

Yes, if I change channel width to 40 (which I don't want to do on the 2.4 ghz band) then the speed will increase.

Why in the world would N mode, 20 width and WMM on result in a speed equivalent to a low powered 802.11b device?

#2

Will be fixed in next release coming hopefully end of month.

#3

i dont really have that issue, changing the rts/cts values and beacon along with distance helped me out. i also had power to 25 or 23 and n mode with 40 mhz, seems to be pretty stable.

#4

Bandwidth should be 40MHz, else throughput will be halved.

If you're using Auto for channel selection, that's likely the issue... If in the US, try channels 1, 6, & 11.

  • If you're using a PC, wifi card settings should mirror the router's
    • Channel
    • WMM
    • Type A, AC, or N (depends on manufacturer as to which they list)

As @sycohexor said, you will also likely want to adjust transmit power.

#5

At least on master for an Archer C7, with an older Nexus 5x Andriod phone, I'm seeing ~50-85 Mbps downstream on 2.4 GHz at a variety of locations.

Edit: DSLReports speed test, Chromium mobile browser, OmniROM, phone's RSSI approx -65 to -55 dBm, distance to AP 10-15 m (through various home walls). Upstream speed capped by Comcast link; tests indicated ~25 Mbps on 25-30 Mbps link.

Nothing special in my config, that I know of

config wifi-device 'radio24'
	option type 'mac80211'
	option channel '6'
	option hwmode '11g'
	option path 'platform/qca955x_wmac'
	option htmode 'HT20'
	option require_mode 'g'
	option disabled '1'

leading to the hostapd config that starts with:

driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=g
basic_rates=60 120 240
beacon_int=100
channel=1


ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

interface=wlan1-1
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=<redacted>
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=<redacted>
bridge=<redacted>
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=<redacted>
#6

In the past some ISP have set DSCP that causes this problem. Try doing a packet capture and see what DSCP values are on the packets.

#7

DSCP, you mean quality of service right? QOS

#8

Yes the DSCP marks on the packets are interpreted by the WMM queues and if they put some bogus values there it can make your packets have the lowest priority possible, and this tends to make your system slow to a crawl. If you put more meaningful DSCP values on your packets, your WMM will work better. You can put custom iptables rules to change the DSCP.

see for example: https://www.reddit.com/r/networking/comments/20j2bi/comcast_leaking_internal_dscp_cs1_to_customer/

#9

That was with Comcast and was a bug in Broadcom drivers. Tomato firmware has a specific option to strip DSCP values for this reason.

It's probably fixed in drivers, but those DSCP fields should not be populated.

#10

I will see how it goes with the new release, I can wait.

Guys though, you shouldn't be using 40 MHz in the crowded 2.4 GHz band. It's bad for everyone as it promotes interference. You will get 40-50 Mbps download throughput on a N 20 MHz channel as it is. If your ISP connection is only 25 Mbps you really don't need more. If you do, use the 5 GHz band and use a,n or ac there instead where you will get higher throughput if you need it. Leave 2.4 for 20 MHz b, g, and n. It's actually in the wifi specification not to use 40 in the 2.4 band.

"According to 802.11-2012, APs and routers must default to 20 MHz bandwidth mode in the 2.4 GHz band. They may switch to 40 MHz bandwidth mode only after satisfying multiple criteria, including no "fat channel" intolerant bit set and no interfering APs. In addition, to meet spec, APs are not allowed to have a "40 MHz only" mode in the 2.4 GHz band."

#11

If you use SQM, there are settings for dealing with DSCP. There is a "squash" or "ignore" incoming packet DSCP, Anyone know if these functions will eliminate this problem where badly labeled packets would cause issues? You can set both incoming and outgoing speeds to 0, then the SQM won't throttle anything. Could be a quick and easy way to test it for the OP...

I agree about avoiding 40Mhz channels, especially if there's more than a few faraway stations out there. You not only possibly interfere with more of the others, you also open yourself up to more of them interfering with you.

#12

It was worth a try.

I changed both Squash DSCP on inbound packets (ingress), Ignore DSCP on ingress from values of 0 to 1.

fast.com produced a download speed of 510 Kbps. Restoring it back to legacy mode and leaving the phone in the same position on the table produced a speed of 14 Mbps.

Looking forward to trying the improvements in version 18.