Hi Johannes,
On 10/21/2016 03:30 AM, Johannes Berg wrote:
Hi,
Userspace tends to display a wifi icon with the rssi shown as a
number of "signal bars", usually 4, 5, or 6.
It's actually not clear to me that this is really how it should be.
There's a point to be made that taking a more holistic "link quality"
would be a better choice. That's related, but maybe can be a separate
discussion.
Can you elaborate on this 'link quality' idea?
and a hysteresis value to be used in the same way as with the
NL80211_ATTR_CQM_RSSI_THOLD attribute, or even modify it to allow
multiple thresholds to be given but that would need a problematic
driver api change. What would be the best way to do that?
So ... I don't think there's a good way to do this at all.
The problem is that you really want this to be offloaded to the device,
*especially* if you care about low power usage, because you absolutely
don't want to be processing each beacon (which is typically what we
derive the data from today) in the host CPU - you want those to be
filtered by the device so you don't wake up the host CPU every ~102ms.
Yes, this would be ideal.
Without offloading to the device, your patch is actually fairly much
pointless, because you've already woken up the host CPU, at which point
punting to userspace probably isn't all that much more expensive over
the cost of waking up the CPU in the first place.
Requiring user space application to process every beacon seems like a
cop-out to me. Kernel should provide a proper API for this. That way
if the hardware / drivers add offloading support for this in the future,
userspace can be blissfully ignorant.
Not to mention that the cost of waking up the process, sending a netlink
message, having userspace process the beacon, etc is not insignificant.
Looking at the code, it seems like only a single driver could support
this in a pseudo-offloaded fashion (iwlmvm), where all the others that
offload it today would not be able to support this API at all, unless
they fall back to complete software processing which, as I wrote above,
will have far worse power consumption consequences.
Therefore, adding this API just for mac80211 seems pretty pointless,
especially since you're targeting this for IoT, where I expect people
will be using full-MAC chips rather than soft-MAC, with the consequence
of not even using mac80211-based drivers. Oops.
The scope is not limited to IoT devices. This has to work everywhere.
So we need a proper solution to report signal strength / signal quality
without resorting to polling or having userspace process every packet on
the WiFi device. Suggestions?
The assumption is that you can't simulate the same behavior with just
the current NL80211_ATTR_CQM_RSSI_THOLD attribute.
Is that true? Technically, it seems that perhaps if you wanted to have
a few ranges, you could always pick one that's currently active, and
program that into the driver/device, with a hysteresis big enough to
extend to the edges of the next range, or something?
Let's say you're currently sitting at -50dBm, and want your ranges to
be -100..-80..-60..-40..-20. Then you could program -50dBm with
hysteresis of 10dBm, and it'd tell you when you move below/above?
This probably won't really work, the hysteresis probably won't be
honoured precisely enough by all drivers. Or we can just fix the
drivers, I guess. However, if you're just at the edge of your range,
e.g. when your current signal strength is -60dBm, you'd still flip-flop
in and out of that range continuously, although userspace could just
program a different threshold/hysteresis for those cases as well.
Anyway, not sure this can be made to work, and drivers would play ball.
This sounds really brittle. Furthermore, we also need a facility to
know when signal strength is getting low to trigger roaming logic. This
would mean sharing CQM facility between roaming & signal strength
notifications. As you wrote above, things become quite impractical.
Regards,
-Denis
