Re: Calculation / algorithm of the 5 GHz vs. 2.4 GHz network selection

James Prestwood <[email protected]>
Newsgroups dev.linux.lists.iwd
Message-ID <[email protected]>
Hi Martin,

On 11/10/24 7:04 AM, Martin Petzold wrote:
> Hi James,
>
> Am 28.10.24 um 12:35 schrieb James Prestwood:
>> Hi Martin,
>>
>> On 10/26/24 12:28 PM, Martin Petzold wrote:
>>> Dear James,
>>>
>>> could you please point me to the calculation / algorithm of the 5 
>>> GHz vs. 2.4 GHz network selection.
>>
>> In the future you can still ask anything on the mailing list, that 
>> way others can use this info later on. First we separate network 
>> selection and BSS selection. Network selection is simply a MRU (Most 
>> Recently Used):
>>
>> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/network.c#n235 
>>
>>
>> Once a network is identified the individual BSS is selected. Each BSS 
>> is given a rank which is heavily based on a theoretical data 
>> throughput calculation. This is based on information the BSS 
>> advertises. Basic rates, HT, VHT, EHT information is all used to 
>> derive an estimated data throughput:
>>
>> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/wiphy.c#n988 
>>
>>
>> Only then does 5GHz and 2.4GHz come into play. There are configurable 
>> weights that can get applied on top of the final rank including a 
>> preference to 2.4GHz, 5GHz, or 6GHz:
>>
>> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/scan.c#n1700 
>>
>>
> Thanks, I checked already and will do some more calculations.
>
>
>> The modifiers can be configured to prefer one band over the other in 
>> main.conf:
>>
>> [Rank]
>> BandModifier2_4GHz=1
>> BandModifier5GHz=2
>> BandModifier6GHz=3
>>
>> These values will be multiplied by the calculated rank.
>
> Thanks. However, I am not sure if I understand your suggested values 
> right. Therefore, some questions:
>
> 1. Would the stated values be something realistic? Or should it 
> actually be decimals?
>
> 2. Does your suggestion mean higher ranking for 6 over 5 over 2.4 GHz? 
> These are not the default values, right?

These are not suggested values, just an example. You will have to decide 
what works for you. IWD will do its normal ranking calculation and come 
up with some number, R. Then:

if (2.4 GHz) {
    R = R * BandModifier2_4GHz;
else if (5 GHz) {
    R = R * BandModifier5GHz;
...


>
> What we observe and would like to improve:
>
> - We have two devices in a building with an enterprise roaming 
> environment (Aruba) with 2.4 an 5 GHz network on the same SSID
> - The building has very thick and obviously radio blocking walls (e.g. 
> I don't have mobile network with my network provider; others have)
> - We have our device and a recent MacBook Pro as a reference device
> - Both devices are more or less at the same (fixed) place
>
> Now we see, that our device (IWD+brcmfmac) almost always connects to 
> the 2.4 GHz network (only once I have seen 5 GHz connection). However, 
> in this network the measured data rate is mostly around only 7-10 
> Mbit/s (in other setups we have 50 Mbit/s = backbone data rate in 2.4 
> GHz - so everything is working!). Sometimes there are connection 
> losses, but with the latest patches things seem to be rather stable. 
> In the very seldom cases our device connects to the 5GHz network, we 
> have measured 180 Mbit/s.
>
> The MacBook Pro mostly connects to the 5 GHz network (but also seen it 
> on 2.4 GHz) and there we get measure data rates of crazy 280 Mbit/s 
> (more than ours, because our device only has 1x1 MIMO)! However, if 
> the MacBook Pro connects to the 2.4 GHz, the measured data rate also 
> goes down to around 10 Mbit/s.
>
> We don't know exactly why this happens (because usually 2.4 GHz would 
> go better though walls), but maybe it is simple overloading of the 2.4 
> GHz bandwidth. But, we are not talking about a heavy crowded place. 
> The infrastructure provider does not see any backbone or structural 
> overload. But they are also not really supportive and precise on my 
> questions.
So I would say you might want to modify the BandModifier5GHz value to 
something like 1.1 or 1.2 (10% or 20% increase in rank for 5GHz 
networks). Without seeing the actual ranking numbers though, I'm just 
guessing.
>
> We will now further improve our logs in order to understand the BSS 
> selection better. But as far as I understand this is not easy because 
> IWD does the initial connection, but brcmfmac could then change the 
> BSS during roaming, which we then don't see in IWD event logs 
> (right?). However, we can read out the connected BSS over time and 
> compare.
>
> 3. Now I would actually like to give the 5 GHz network a higher 
> preference, BUT without loosing the connection. I am worried about the 
> device getting into a connection loop if I rank the 5 GHz networks a 
> lot higher and then only connections to those BSS take place and maybe 
> fail all the time (in terms of very bad connection and dropping after 
> a short time). Also if I am right, I cannot really influence what 
> brcmfmac does, right? Or will it only roam to same band BSSes?
As far as roaming no, you can't influence brcmfmac. IWD does get 
notified when the firmware roams, but has no control over it.
>
> 4. I wonder, why do you somehow rank 2.4 GHz preferred in the default 
> setup. Shouldn't the 5 GHz network always be preferred, if the signal 
> is more or less okay (because there is far more bandwidth available 
> and mostly all legacy devices fill up the 2.4 GHz)?
Its based on the rank that IWD calculates for each BSS. For two BSS's 
that advertise the _exact_ same capabilities it comes down entirely to 
RSSI. Otherwise its heavily influenced by capabilities advertised. 
Basically the theoretical speed that it can support, which does take 
RSSI into account. Since 2.4GHz has much better penetration I'm assuming 
those BSS just have much better RSSI than 5GHz, but I can't say for sure 
without seeing logs. Its very easy to read the logs and see what IWD 
ranked each BSS.
>
> Thanks,
>
> Martin
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.