Proposal to change the default wifi beacon interval from 100 ms to 50 ms

Feature Requests
1

At some point I started to experiment strange wifi disconnects, and I think I fixed changing the wifi beacon interval.

I found the, still hot, bug report in linux kernel: iwlwifi: 8260: frequently disconnects since Linux 5.1 "No beacon heard and the time event is over already" - WIFI-25906, which is also referenced in freebsd wiki too

OpenWrt is mentioned in that bug report, because they say that the problem could be fixed from the AP side (and OpenWrt facilitates on that). Someone says in the bug report:

I'll try to provide firmware logs later, but for now I've found that changing "Beacon Interval" from the default 100 ms to 50 ms on my OpenWrt AP fixes the problem. Perhaps this information is useful.

Nobody complains anymore about this, the discussion is more focused now on wether we should fix it or not in the client side when you cannot change the AP.

I tried to change it (see appendix on how), and it is working good since I changed it on 2023-04-17 (1 week and 1 day ago). I don't know if start saying to people that they should change that beacon interval one by one, or just proposing this option as a default one.

Then, can we change the beacon interval from 100 ms to 50 ms? I think it will improve users connecting to the AP without having to look into the details.

Related

Appendix: how to change wifi beacon interval from 100 ms to 50 ms

uci set wireless.radio0.beacon_int='50'
uci set wireless.radio1.beacon_int='50'
commit

In the web interface it is around 6 clicks:

image
image1009×434 48 KB

image
image960×671 55.2 KB

And then scroll down to save and then save and apply

5 Likes
2

What is "beacon intervall"?

Source of explanation: https://openwrt.org/docs/guide-user/network/wifi/basic#common_options

Name Type Required Default Description
beacon_int integer no 100 (hostapd default) Set the beacon interval. This is the time interval between beacon frames, measured in units of 1.024 ms. hostapd permits this to be set between 15 and 65535. This option only has an effect on ap and adhoc wifi-ifaces
3

I did some digging about beacon rate and I think it is worth noting the trade-off in terms of battery life this change can have, when client devices increase / decrease their beacon rate intervall as described here: https://kontakt.io/blog/beacon-interval-configuration-guide/

Increasing the rate beacons send out on the AP will increase the power usage of the AP. I wonder, if this increase in power usage potentially could get compensated in terms of energy savings by better connectivity with client devices with higher beacon intervall rates (e.g. > 100 ms)?

2 Likes
4

Shorter beacon interval means more airtime spent on beacons. It gets more significant with default settings which send beacons at a slow MCS or even 1 Mb legacy rate, and with newer standards that send more information in a beacon.

Beacon interval = 50 is a workaround for a specific bug in a particular vendor's closed-source firmware. That should not be encouraged.

3 Likes
5

Relevant: DTIM period and Beacon interval relationship

Name Type Required Default Description
dtim_period integer no 2 (hostapd default) Set the DTIM (delivery traffic information message) period. There will be one DTIM per this many beacon frames. This may be set between 1 and 255. This option only has an effect on ap wifi-ifaces.

https://routerguide.net/dtim-interval-period-best-setting/:

The DTIM count is the frequency of data transmissions per each beacon broadcast. For example, a value of 1 will have DTIM broadcast every beacon, and a value of 100 will have DTIM broadcast every 100[th] beacon.

Now, depending on your beacon interval, you can calculate the frequency of DTIM broadcast in terms of time period. If you have a beacon interval of 100 ms and a DTIM value of 1, the DTIM is transmitted every 100 ms which equates to 10 times per second. If you have a beacon interval of 1000 ms and a DTIM value of 2, the DTIM is transmitted once every two second.

DTIM apparently plays another key role for when client devices come out of "sleep mode", hence low power consumption mode.

Anyway, I think any change of these defaults would require extensive testing.

Articles like https://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html claim connectivity issues and missed notifications can stem from (Apple) client devices ignoring multicast messages like DTIM and only wake up at certain timings. The recommendation was to set DTIM to 3, but that article is from 2016. Things could have changed long ago. Since there is this close relationship between beacon interval and DTIM, I very much would suggest testing is required (with many different devices), before changing default values.

1 Like
6

Try the approach described here: https://www.dslreports.com/forum/r14241618-Theory-on-Optimizing-a-802-11-Beacon

I personally had a lot of issues with Apple devices not staying connected when I changed the values to 70, but setting them to 97 or 101 helped a lot.

1 Like