|
After more
research I'd suggest the following metric to be used for channel
selection: /* Calculate a 'utility' metric based on signal strength and real world data rate. The balance between the two characteristics can be debated. The choice here is between a 5GHz channel at 450 Mbps and 2.4 GHz at ~20 Mbps. The power of the signal (in dBm) is logarithmic and can easily dominate the metric. */ if((*channel_data)->channel > 14) { // Standard Frequency Real World Speed // 802.11n 5 GHz 450 Mbps (*channel_data)->metric = 450 * 1000000 * pow(10, (*channel_data)->signal_level_dB / 10.0); } else { // Standard Frequency Real World Speed // 802.11g 2.4 GHz 10 - 29 Mbps (*channel_data)->metric = 10 * 1000000 * pow(10, (*channel_data)->signal_level_dB / 10.0); } This approach favors quality over quantity. I have revised the C code to reflect this. As noted before, the quality value reported by an iwlist scan is nothing more than another way of expressing the signal strength but it 'hides' the fact that the signal strength is logarithmic. On 10/26/19 3:20 AM, Thomas Haller
wrote:
On Fri, 2019-10-25 at 14:48 -0700, Clive McCarthy wrote:I think the data rate reported is the maximum data rate that the channel can support. It isn't a measure of the possible throughput which would take into account noise (noise being "anything other than the desired signal", which was what I was taught many, many years ago). It is clear that the algorithm isn't taking into account possible co-channel interference. If a 5GHz 500Mbps connection is 30dB down from a 2.4GHz 54Mbps signal then the 500Mbps is just pie- in-the-sky. A connection with a lot of co-channel interference will cause the many, many retries and the effective data rate collapses. Please think in dBm. The percentage numbers mean absolutely nothing. As I said, my phone measured a 10dB difference and nmcli reported only a 90% to 55% ratio -- which is flat-out wrong. The percentage numbers are bogus and should NOT be used to compare signal strengths. The antenna on my phone will have a different gain to the antenna on my laptop but the signal strength ratio is valid. Whoever wrote the signal strength code isn't a radio engineer.NetworkManager itself does not at all care about the signal strength. - for example, when autoconnecting a Wi-Fi device with having multiple candidate profiles in range, then the winner is not chosen based on the signal strength. Instead, it's chosen based on "connection.autoconnect- priority" and "connection.timestamp". - roaming is not done by NetworkManager, but by wpa-supplicant. Hence, NetworkManager doesn't care about the signal strengh in this case either. - no matter how bad a signal gets, NetworkManager won't decide to pull the plug. It will stay connected until wpa-supplicant says that it lost the connection. The only place where the signal strength matters it to sort (and color- code) the output of `nmcli device wifi`. It's purely informational output for the user. Of course, that output should reflect the actual situation, but your actual Wi-Fi expirience is unaffected by the accuracy of the strength/percentage.Please think in dBm. The percentage numbers mean absolutely nothing.in dBm, better signal strength means a lower dBm number. Likewise, when converted to percentage, then a lower dBm always means a higher-or-equal percentage. So, a better percentage does mean a better signal! What is however not clear how much better 1% is. For example, there might be better conversions from dBm to a percentage value that reflect the actual signal strength better ([1]). Anyway, the formulay for converting the numbers is quite simple. See [2]. We certainly would welcome help from a radio engineer to improve this! [1] https://www.adriangranados.com/blog/dbm-to-percent-conversion [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/wifi/nm-wifi-utils.c?id=487b5df7169895cf132997b0bc7f402479043066#n784 best, ThomasOn 10/25/19 2:21 PM, Dan Williams wrote:On Fri, 2019-10-25 at 11:17 -0700, Clive McCarthy wrote:I've done a quick survey around the building and NM is always selecting the highest data rate AP despite stronger signals from other APs. This happens even when the data rate difference is relatively small.Again, it's actually the supplicant making the choice. But since NM is the face of things here, it gets ultimate responsibility for the behavior I guess.As an example:signal 90% data rate 54 Mbps signal 55% data rate 65 Mbps -- activea bad choice. If the signal numbers were in dBm things would be clearer.Typically you want faster data rates, not stronger signal (to a point). For example if you were right next to your 802.11g AP with a max of 54Mbps, but had a 50% signal to an 802.11ac AP with a likely rate of 400+Mbps, why would you want to connect to the stronger-but-slower AP? DanI put my Android phone next to my Linux laptop and got:-48dBm -58dBmrespectively for the two channels a ~10dB difference. Way, way more that the ratio of 90% to 55%. So forget this % nonsense. On 10/23/19 12:41 AM, Thomas Haller wrote:On Tue, 2019-10-22 at 15:02 -0700, Clive McCarthy via networkmanager- list wrote:You know, I wish that the Network Manager would report the signal strength in dBm instead of the silly sector icon. But that is for another day.nmcli -f SIGNAL,BSSID,SSID device wifi nmcli -f ALL device wifi best, ThomasOn 10/22/19 2:24 PM, Dan Williams wrote:On Tue, 2019-10-22 at 13:37 -0700, Clive McCarthy wrote:I rand the commands you suggested but the response doesn't look like a log dump. I guess they just enable logging. method return time=1571775394.161873 sender=:1.8 -> destination=:1.507 serial=32493 reply_serial=2 method return time=1571775429.864202 sender=:1.8 -> destination=:1.508 serial=32496 reply_serial=2 method return time=1571775528.578915 sender=:1.8 -> destination=:1.510 serial=32636 reply_serial=2 Can you point me to where the log files might be or at least their names.If your distribution uses systemd, they may be available with: journalctl -b -u wpa_supplicant if your distro does not uses systemd, then it'll be wherever syslog dumps that kind of output, like: /var/log/messages /var/log/wpa_supplicant.log /var/log/daemon.log DanOn 10/22/19 12:16 PM, Dan Williams wrote:On Tue, 2019-10-22 at 11:17 -0700, Clive McCarthy wrote:Thanks for your reply. My laptop, when first opened, reports (via the Network Manage, I suppose) that it is disconnected from the network. After a second or two it reports being connected. And it is. However, as I noted, the manager seems to choose the last known connection. This is a satisfactory algorithm for a fixed computer and for a computer connecting to a single AP. It isn't good for a movable computer with multiple APs. The Intel WiFi adapter is forced to shutdown when the computer is closed because there is a bug in the Intel-WiFi driver that doesn't handle suspend correctly. That is why there is a disconnect- connect sequence.In this case we'd need the wpa_supplicant logs described below to diagnose why the supplicant is picking that specific AP rather than another. DanOn 10/22/19 10:05 AM, Dan Williams wrote:On Mon, 2019-10-21 at 20:42 -0700, Clive McCarthy via networkmanager- list wrote:I have a situation where I have multiple APs in a building all with the same SSID and WPA key but set to non-clashing frequencies. When I close my laptop and WiFi shuts down and I move to a new location the Network Manager seems to connect to the original AP, rather than one with a much stronger signal. The algorithm for AP connection is suboptimal (in other words dumb). The selection process should scan ALL APs, figure out which ones are known (SSID and WPA); measure their signal strength and then choose the known AP with the strongest signal. How hard is that?This is what NetworkManager should already be doing. Two things to check: 1) NetworkManager depends on being notified by systemd or upower that the laptop has suspended so that it can reconfigure when it wakes up. It should be pretty clear if that's happening through the NetworkManager logs because it will say that it's going to sleep and waking up. For example: NetworkManager[1198]: <info> [1571720491.7590] manager: sleep: sleep requested (sleeping: no enabled: yes) NetworkManager[1198]: <info> [1571720491.7599] device (wlp61s0): state change: disconnected -> unmanaged (reason 'sleeping', sys- iface-state: 'managed') NetworkManager[1198]: <info> [1571720491.7615] manager: NetworkManager state is now ASLEEP NetworkManager[1198]: <warn> [1571752873.5481] sup- iface[0x55f38553aaa0,wlp61s0]: connection disconnected (reason -3) NetworkManager[1198]: <info> [1571752873.5504] device (wlp61s0): supplicant interface state: completed -> disconnected NetworkManager[1198]: <info> [1571752873.5803] manager: sleep: wake requested (sleeping: yes enabled: yes) NetworkManager[1198]: <info> [1571752873.6556] device (wlp61s0): state change: activated -> unmanaged (reason 'sleeping', sys- iface- state: 'managed') 2) enabling debug logging in wpa_supplicant with these two commands will show you exactly what's going on: sudo dbus-send --system --print-reply -- dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true sudo dbus-send --system --print-reply -- dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump" this will dump logs to wherever your system typically sends system logs, like the systemd journal or syslog. Once you have these logs, please review them to ensure there is no private information and then attach them to a reply so that we can figure out what's going on. Thanks! Dan_______________________________________________ networkmanager-list mailing list networkmanager-list gnome org https://mail.gnome.org/mailman/listinfo/networkmanager-list |
Attachment:
wifi_selector.c
Description: Text Data