|
The definition of a Bel (named after Alexander
Graham Bell) is just the logarithm (base 10) of a number https://en.wikipedia.org/wiki/Decibel.
A decibel is just ten times that. The purpose of taking the
logarithm is to enable a simple representation of widely
varying numbers that would be troublesome if presented on a
linear scale. It also has the merit that adding and
subtracting the logarithmic numbers is the same as multiplying
and dividing which is what one commonly needs to do for signal
connections.
Since a decibel is just a ratio it does not represent an absolute signal level. As a consequence a reference level has to be assigned. In the case of radio and other signals it is commonly one milliwatt, thus we have dBm -- a logarithmic signal strength relative to one milliwatt. A milliwatt of radio signal is still a massive amount. Even a very strong signal will be just 1,000th of a milliwatt -- a microwatt. Because this is expressed logarithmically signal strength numbers are invariably negative -- it's a negative exponent. A 1% difference is a ratio of 1/100 = 0.01 so in decibels that is: log⏨(0.01) = -2.0dB-30dBm is a very good signal. So far, mathematically simple. However, signal
strength isn't enough because of noise. All signals have noise
and the transport of information is what is important.
Claude Shannon https://en.wikipedia.org/wiki/Claude_Shannon
did fundamental work in this area a long, long time ago.
I don't know what a supplicant is? Is it the WiFi driver? It is clear that iwlist has good data that represents what the various channels can offer. I presume that NM is the final arbiter of which channel is chosen for the connection. As I understand WiFi, the technology does not support roaming at all, unlike wireless phones which dynamically associate with cell towers. In my circumstance the radio is shut down and restarted every time I change location so NM gets to select the AP from scratch. It just picks the wrong one! 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 |