Switch AP by estimated bandwith, not signal strengh / Feature Requests / NetSetMan Support

NetSetMan Support

Search for already answered questions about NetSetMan (Pro) or ask new ones

You are not logged in.

#1 2021-03-29 19:51

darkwell
Member
Registered: 2021-03-29
Posts: 3

Switch AP by estimated bandwith, not signal strengh

Hi,
switching to the AP with the best signal is a very poor choice. See https  imgur.com/a/2NagXGv
There are two entries with 99% but very different performance. Also there is a 94% with only 144 Mbps.

Instead of using signal strength, I suggest to use signal strength multiplied by Mbps as an estimation for the resulting performance. That way, it will never use a slow connection if a fast one is available.

Thanks.

Offline

#2 2021-03-30 09:55

NetSetMan Support
Administrator
Registered: 2005-08-06
Posts: 1,833

Re: Switch AP by estimated bandwith, not signal strengh

A wireless network does not provide any information about its actual speed performance. The values in the Mbps column are determined by analyzing and combining different WiFi packet frame protocol details. The result is a theoretically maximum supported speed. In no way is this a representation of the actual connection speed. The access point may or may not use any of the supported protocols or available antennas. Long story short: The calculated max. Mbps value cannot be used for a reliable switching algorithm, because it is rather a guess.

The signal strength, on the other hand, is a real value that is constantly measured by the WiFi driver. While it still doesn't tell anything about the actual connection quality, it is an absolute value based on a measurement.

Multiplying those values doesn't make sense to us.
In practice, a 20% 1733 Mbps connection will most likely not be as fast and stable as a 80% 300 Mbps connection.
Also a 1733 Mbps connection is not necessarily faster than a 325 Mbps connection with the same signal strength if it has lots of clients and traffic on overlapping channels while the other one has a clear channel.
Different types of hardware are relevant as well, as a repeater for example has only about half the performance of a wired access point.

We understand the background and intention of your suggestion, but implementing a switching condition that is based on guesses and on an arbitrary calculation does not seem reasonable.

It is rather uncommon to have multiple access points with such a different performance for the same network. Wouldn't you rather replace a slow 144 Mbps access point than trying to avoid it by algorithms?

It is probably not the solution you wanted to hear, but it would really make sense to replace old access point hardware to improve the speed, stability and quality of your wireless (mesh) network.

Offline

#3 2021-03-30 11:32

darkwell
Member
Registered: 2021-03-29
Posts: 3

Re: Switch AP by estimated bandwith, not signal strengh

Hi,
It's not necessary to have actual information about the speed. A weak estimation is still better than nothing.

It's not uncommon to have the different performance. My access points are actually quite recent:
AVM repeater 1750e about 5 years old
AVM repeater 3000 the current repeater flagship
AVM Fritzbox 7490 and 7590, the latter one being the current flagship
And an CPE 210 which is slow, but has a long range.

So this is not about old hardware, but the fact that they all have a slower 2.4 GHz AP included in the same device. (Except for the CPE which is 2.4 only) The other APs are all fast and can achieve 866 or even 1733 Mbit/s. In practice they are slower than they could be because of poor choice where to connect. This has not been considered properly when WiFi has been designed. All the mesh and roaming things came up later and this has not been done well at all.

The worst thing is the repeater 3000. It has one 2.4 GHz Band and two 5 GHz Bands. The first 5 GHz only supports 80 MHz Channel with, while the second one supports 160 MHz. Hence, it is way faster and can easily use the full bandwidth of the cabled LAN connection. Obviously, they always have almost the same RSSI, because they are at the same place because it's all in one device. Unfortunately, on my device, the slower one has a slightly better RSSI so all clients use the slower one! This is the main problem at my site. It's not about old hardware, it's the latest and best repeater currently available from AVM, a popular german manufacturer.

The performance of repeaters has to be considered when building the network. There is no information available to the clients about how fast the backhaul is, hence this is no argument against or for my suggestion. It can be better or worse but is not related to the roaming decision.

I agree that 20% 1733 Mbit may be worse. Because at 20% there will be probably no connection at all. But this is only about fine tuning the calculation, not the general idea being wrong.

Note that my APs are all wired. Repeater is just the product name.

Offline

#4 2021-03-30 11:39

darkwell
Member
Registered: 2021-03-29
Posts: 3

Re: Switch AP by estimated bandwith, not signal strengh

If you agree to the general approach, I'll do some measurements and try to find a better estimation formula.

Offline

#5 2021-03-31 10:13

NetSetMan Support
Administrator
Registered: 2005-08-06
Posts: 1,833

Re: Switch AP by estimated bandwith, not signal strengh

darkwell wrote:

But this is only about fine tuning the calculation, not the general idea being wrong.

The general idea isn't wrong, but it is very unlikely that there is an adequate general solution for this problem. If we were to integrate a new feature like "Automatically switch to the WiFi access point with the best connection of the current SSID", then this would have to work reliably in all constellations, not just the ones that are similar to yours.

Without analysing this thoroughly, we don't see how there could be one formula for solving this issue. You are welcome to test this for your constellation and share your results as a starting point for us. But we won't be able to implement such a feature just for your constellation. We can queue this request with our other tasks and when we get to it, your results will help with our analysis.

Offline