Wifi RX rate drops down to 1.0 Mbit/s every few seconds

I'm using a FritzBox with an Atheros AR9227 wifi chip (ath9k module). Every few seconds to RX rate drops down to 1.0 Mbit/s. Interesting is that this only seems to happen if the connection is idle. If I'm downloading something the connection is stable. Therefore my first thought was some kind of power saving, but it seems off per default.

# iw dev wlan0 get power_save
Power save: off

I'm quite clueless. Is someone experiencing similar issues with the ath9k module and has some tips to track this issue down? There are no output in the syslog/kernellog regarding the wifi when this happens.

# iw dev wlan0 station dump
Station 54:67:51:56:74:53 (on wlan0)
	inactive time:	560 ms
	rx bytes:	549755049
	rx packets:	1291921
	tx bytes:	16079455
	tx packets:	112457
	tx retries:	5370
	tx failed:	0
	beacon loss:	0
	beacon rx:	456658
	rx drop misc:	13430
	signal:  	-47 [-47, -57] dBm
	signal avg:	-49 [-49, -59] dBm
	beacon signal avg:	209 dBm
	tx bitrate:	130.0 MBit/s MCS 14 short GI
	rx bitrate:	1.0 MBit/s
	expected throughput:	44.677Mbps
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	1
	beacon interval:100
	CTS protection:	yes
	short slot time:yes
	connected time:	49319 seconds

It seems to be "common" behavior that the dynamically negotiated rates drop when idle. In the case of the multiple ath79 and ipq40xx devices I run, the way that I have them configured, they drop to 6 Mbit/s when reasonably idle. I suspect that the difference is that I disable legacy rates (which I believe to be 1 and 2 Mbit/s).

1 Like

Is there a way to prevent this behavior? I use the router as a WLAN bridge and I suspect that this is the cause for an often noticeable delay when loading a website.

Out of curiosity, what is the gain when disabling legacy rates?

Beacon frames are sent at the lowest supported rate of the AP.

See, for example, https://r1ch.net/blog/wifi-beacon-pollution


Legacy rates mean the transmitter spends more time on the air, which is less opportunity for others to transmit. Also the b modulations are DSSS, which inherently "splatters" outside the bandwidth occupied by g or n modulation, affecting operation on adjacent channels.

1 Like

One way to test this hypothesis would be to set the supported_rates and basic_rates for the two routers involved to "start" at a robust, high rate between those two devices (and not on your client virtual APs).

@jeff @mk24 wonderful, NOT! :smiley:
I'll read the link and configure accordingly, thanks.

This is the whole concept of minstrel{,-ht}, the rate control algorithm in charge of all mac80211 based drivers (aside from those doing rate control in firmware). Rates are carefully stepped up under load, until excessive packet drops/ retransmissions are encountered, which is when it will slightly back off again - if there is no traffic flow, it ramps down to the minimum rate (for a mobile device (but also changing interference situations) this is essential to remain connected even when the reception worsens). While it will take a (short) while to ramp up again, there isn't really any hurt coming from it (after all, established data rates don't matter if you're not transmitting/ receiving anyways) - and it doesn't require a lot of (background) traffic to remain on the higher end.

There have been quite a few attempts of writing rate control algorithms in the past, both before- and after minstrel (e.g. ath9k had its own at the beginning) - none of them really were a competition. Even today's in-firmware rate control algorithms (e.g. intel) are often more of a pain, than a blessing.


@mk24 I disabled 802.11b, which I assume you meant with "legacy" rates. Although the RX rate still drops to 1.0Mbit/s it's a much better experience. Thanks.

1 Like

Glad that things are working better for you!

On my 2.4 GHz radios, I choose to set

        option hwmode '11g'
        option htmode 'HT20'
        option legacy_rates '0'

I don't force 802.11n here (require_mode), though I probably could these days.

On my 5 GHz radios that don't need to connect to older devices (such as iPhone 5s)

        option hwmode '11a'
        option htmode 'VHT80'    # as appropriate for your channel, jurisdiction, and environment
        option require_mode 'ac'
        option legacy_rates '0'`

With devices that don't support 802.11ac present on that AP, that changes to option require_mode 'n'

See further https://openwrt.org/docs/guide-user/network/wifi/basic#common_options

1 Like

The RX rate is determined by the other end. The AP can't control what it receives only what it transmits. WiFi is not well thought out in that the AP has little control over what the clients do.

I have encountered a problem that might be similar. According to my observations, Short GI is to blame; it appears when the speed drops.

There is no traffic, and speed seems very good. So it decides, "Cool, let's heat it up!", and turns on Short GI. Then the traffic hits, and turns out the situation is not as good as it thought (there are walls in the way and stuff), so the speed plummets, apparently dropping a few packets in the process.

This is on Mikrotik RB941-2nD with ath9k on 18.06.8. I have another router right next to this one - a TP-Link TL-WR740N, also with ath9k, but on Chaos Calmer. I'm trying to compare those routers; they have the same WiFi configuration, and I'm enabling WiFi on one or on the other. And it works very well on a TP-Link - no speed drops.

The first difference between them is that there is no "Short GI" appearing on the TP-Link. I guess it's probably not supported on Chaos Calmer? Another difference is that the TP-Link has a big antenna, and the Mikrotik uses an internal one, but it's much more sensitive, so I've expected it to actually be much better than the TP-Link. (Small but very sensitive antennas => if this was the issue, TX would be suffering, not RX.)

So to prove my conclusion, we have to try turning off Short GI, and see if it changes anything. Now the question is, how to turn off Short GI on OpenWRT? Apparently, it's impossible. There was already a question about this: Daemon.err hostapd: Driver does not support configured HT capability [SHORT-GI-40] . I'm on 20 MHz, not 40, but I guess there is not much difference.

Apparently, Short GI is now built into the driver. I wouldn't mind rebuilding OpenWRT with some parameters for the kernel modules to test this, but I don't think I can figure out how exactly do I disable it. Maybe even a kernel boot option would be enough?..

Now the issue makes sense!

I wonder if the OP is also using antiquated firmware...


I've found this:

I don't really know what to make of it, but seems like it was not supported or optional before, but now it's built into the driver. Now the question is, how do we disable/remove it. :slight_smile:

I think the problem is the opposite - the OP is using current firmware, which introduced the problem. If they were on antiquated firmware, there wouldn't be a problem because there is no Short GI that is causing it. :slight_smile:

Hmmm... was under the impression that disabling legacy got rid of 1mbit and 6mbit was then the minimum, is that not the case? If so, can one disable rates to keep the airtime fairer?Off to do some reading...

Again, the AP cannot control what the client will send. The AP is always ready to receive at any rate even though with legacy_rates 0 it will never transmit at b rates.

The client is using a similar algorithm as the AP where it will try higher and higher rates until too many packets are lost (which may or may not mean the signal reaching the other side is too weak to decode the high rate), then it will fall back to a lower rate.

1 Like

I've upgraded my device to 19.07.3, and it seems to work quite well now - no speed drops.

You can use basic rates option. For it to register though, you need to manually edit hostapd.sh file like below:

	echo $ifname
	if [ "$ifname" = "wlan0" ]; then
		append bss_conf "supported_rates=480 540" "$N"
		append bss_conf "basic_rates=480 540" "$N"	
		#append bss_conf "beacon_rate=480" "$N"	
	if [ "$ifname" = "wlan1" ]; then
		append bss_conf "supported_rates=120 180 240 360 480 540" "$N"
		append bss_conf "basic_rates=120 180 240 360 480 540" "$N"	
		#append bss_conf "beacon_rate=120" "$N"	

For me lowered rates by default confuse my mobile phones internal roaming algorithm and connects wlan0 (5GHz) at very low rssi. This edit keeps it on wlan1 (2GHz) w/o unnecessary interruptions (sometimes I had disconnection issues as well when that happen, now they are gone).