Re: Prevent auto scan in wireless devices (Aloisio Almeida)

[Howard Chu <hyc symas com>]

Dan Williams wrote:
> On Tue, 2009-01-13 at 14:28 -0800, Howard Chu wrote:
> > I also noticed that in NM 0.7 prereleases, scans did not occur on my ath9k
> > when it was associated, but after 0.7 was released, this behavior changed. (I
> > found the commit that changed this, saying it was removing a hack...) I
> > reinstated the hack on my build, because it was disrupting my streaming wifi
> > traffic. All in all, I would love to see scans only occurring on demand, and
> > not at any other time.
>
> How long does the scan take on your ath9k card, and does buffering not
> paper over any momentary hiccups?  Also, is your machine a desktop
> machine or laptop?

It appears to take a large fraction of a second. This is on an HP dv5z laptop. 
The problem is that when I'm operating at greater distances from my wifi 
router, bandwidth is already reduced and spotty, any additional interruptions 
are enough to tip it over the edge. E.g., trying to watch a video that's 
streaming with a nominal bandwidth of 18Mbps ought to work fine on 802.11g, 
most of the time. On the HP, the scans made the video glitch. On my older Asus 
M6Ne laptop with Intel 2200 card, I never saw this issue. (And I can run both 
laptops side by side to reproduce the glitch on the HP and not on the M6Ne.) 
Removing the scans removed most of the glitches.

> Not scanning periodically means that NM (and the
> supplicant, and the driver) doesn't have a good picture of the network
> topology, and this can have adverse consequences for roaming and
> reconnection.

I guess that might be an issue for some people who move around a lot while 
connected. Hard to imagine. In my case, at home I have only one AP, so no 
matter where I walk around the house, the topology is unchanged. Likewise at 
my office. Surely it doesn't need to do a full scan to monitor the signal 
strength of the AP it's talking to...

As for reconnection - as I said, scanning should be disabled while connected. 
If the connection is lost and a reconnect is needed, then of course you have 
no choice but to scan again.

> If the driver is taking a long time to scan, then the
> driver may need some optimizations as well.  The hack was there because
> long ago, madwifi simply couldn't scan in a reasonable amount of time.
> These days, almost all cards/drivers can scan in a reasonable amount of
> time, and those with hardware assisted scanning like Intel cards can do
> it even faster.

Admittedly, the ath9k driver looks like it still needs work. I refresh my 
driver from the wireless-testing repository every couple of weeks though, and 
it's still an issue.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/