Re: [PATCH 09/13] mac80211: remove hw_scan callback

[Andy Green <andy@warmcat.com>]

James Ketrenos wrote:
> Andy Green wrote:
>> James Ketrenos wrote:
>>> The more passive channels you add (most of 802.11a) the slower the
>>> scanning gets.
>>
>> Well just a datapoint on that (zd1211rw, presumably mac80211 scanned)
>>
>> $ time iwlist mon0 scan
> ...
>> real    0m0.857s
>> user    0m0.001s
>> sys     0m0.004s
> 
> How many channels are being scanned, and how many of those channels are
> passive only?  And can you clarify on 'presumably'?

It's a BG stick, so 13.  'presumably' means I grepped the
zd1211rw-mac80211 dir looking for scan and didn't find anything, so I
"presume" the scan action is driven by mac80211.

>>>> Eliminating the hw_scan callback reduces driver complexity. 
>>> If done right, the stack would set up the list of channels to scan,
>>> whether to scan the channel active or passive, and the template for the
>>> probe request to use. 
>>
>> I think one can reasonably say that's a lot of stuff to support what is
>> a vendor-specific feature that only optimizes what can already be done.
> 
> I think I would say that's a lot of stuff to make software scanning try
> and work as well as hardware scanning does now.  hw_scan() is there now,
> it works, and its twice as fast as software scanning.  The work should
> be to make software scanning better for hardware that can't do hardware
> scan, not to remove the ability for hardware scanning.
> 
> ...
>> Maybe a simpler, more granular way to come at that is in the firmware to
>> allow selection of "beacon only" filtering, or maybe a count of valid
>> CRC packets that got filtered so you can assess if you should look
>> closer at that channel.
> 
> Or maybe just let the firmware do the scan?  :)

Well, let me put it this way... hiding the scan sequencing action even
in the stack seems like a bad thing to me, so hiding it further back
into a modal device-specific firmware action seems really wrong to me.
If scan is moved completely out of kernel mode, and instead the existing
primitive actions (change channel, set monitor mode, use libpcap BPF
filtering) enhanced and exploited to deliver better functionality (see
the latency subject below), the result is leaner kernel code, simpler
and all-in-one-place usermode code AND the architecture of empowering
the simpler already-exposed primitives allow re-use to do things that
aren't thought of yet.

Let's not forget that the bulk of the time this firmware assisted scan
action is doing nothing but letting the radio dwell on the frequency it
selected, for tens of ms.  I'm not sure why including mac80211 in the
loop should make a tremendous difference.

> ...
>> For result latency, at the moment the monolithic scan is atomic, you sit
>> there with nothing and get your results all at once.  With a usermode
>> driven scan, you will get results as you scan a channel, improving the
>> perception of latency.
> 
> The action for finding your particular AP will always be atomic.  If the
> AP you want is on a passive channel and you happen to miss the beacon in
> one pass, now the 4.7s "find the AP and associate via software" sequence
> is 9.4s... or 13.
> There is no 'perception of latency' when it comes to the question of
> "How long after I click the button to turn on wireless do I have to wait
> before I can hit refresh on my browser?"

I was talking about iwlist scan or populating a list of channels in a
GUI, but let me point out that in the case of the usermode
wpa_supplicant hunting an AP, if it is in control of the scan behaviour
because it drives the whole process from usermode as I propose it should
eventually, it becomes quite easy to prioritize the channel hunt order
on probability of where it has been seen before, and to modulate the
dwell time on particular channels as well, all of that done in usermode
according to wpa_supplicant's needs.  Delivering much better performance
 in the typical case.  For all mac80211 drivers at once.

>> It seems it won't make your life that much harder
> 
> Actually it will because we'll end up having to have our users use the
> external mac80211 subsystem for as long as hardware scanning is not
> supported by the kernel.  Accelerated scanning is something end users
> like.  I'm not going to give that up.

Well I don't have any right to tell you to give up on anything, but as
someone whose whole project is completely stalled by his code not
getting into mac80211, I can confidently assert you need to bring
mac80211 along with you in that case.

>> mac80211-based scanning appears to work for you already
> 
> mac80211-based scanning worked as a stop gap.  It is definitely not
> suitable as a final solution.

Hum well, it works, it's not that unsuitable.  It's slower.  It's still
suitable.

>> and we talk about 2 seconds instead of 1 for results now and again.
> 
> It isn't 2s vs 1s -- we're talking 5s vs. 2s... and that's if it finds
> the AP on the first scan, which it doesn't always do.  "now and again"
> is a lot more common than you'd like and when you're using a laptop and
> changing environments, roaming, AP hopping, etc.

Fine: we talk about 5s vs 2s "now and again" and when roaming and AP
hopping.  And there is at least a competing concept to enhance mac80211
to reduce that down below 2s for many typical cases without special
vendor-specific tweaks so that all drivers would benefit.

-Andy