Re: Atheros abg / madwifi trouble

[Sven <sr12 duke edu>]

On Mon, 2005-01-31 at 10:00 -0500, Dan Williams wrote:
> On Sun, 2005-01-30 at 17:11 -0500, Sven wrote:
> > NetworkManager does not work well with my mini Atheros abg card. it can
> > associate ok, but then roughly every minute it looses the connection and
> > the card is scanning/cycling through all channels for about 10 secs or
> > so. during that time iwconfig gives "FF:...:FF" as the AP. it cycles
> > through the channels 3 times, and the associates with the original AP
> > again.
> 
> Sven,
> 
> Ok, I took a look with this card.  The behavior you're seeing is pretty
> much expected, that's the card running its wireless scan so we can
> update our list of access points.  The thing you may not be aware of is
> that the card supports so many frequencies that it takes a _long_ time
> to scan all the channels (somewhere around 10s it seems, from this
> card).  Obviously, since the card isn't associated during that time, it
> cannot send or receive traffic.
> 
> Some observations:
> 
> 1) NetworkManager starts with a 20s scan interval, and if the aggregate
> list of access points does not change with each successive scan, it
> backs the scan interval back to 60s.  If the list changes (an AP drops
> off after the 2m "last seen" check, or a new one appears), the scan
> interval jumps back to 20s.
> 
IMHO this is a lot of scanning & disconnection from the AP. I forced the
card in b-mode only, and it's still scanning and disconnecting for ~4s
every 60s.

> 2) Since the card takes so long to scan, and since no traffic can flow
> during the scan, it doesn't work very well from a user's perspective.
Word! what bothers me most is the "dead time" of disassociation.

> 3) I don't mind tuning the scan algorithm.  I can figure out how many
> channels the card supports, and if its over 14 that means its an a/b/g
> card right now.  I then know that it will take a while to scan, since
> the time that a card must remain on a channel to sense the AP's beacon
> does have a lower bound (a couple hundred ms, something like 150ms -
> 200ms).  Perhaps if the card is an a/b/g card, I should step the scan
> interval back 20s rather than 10.
whatever works... i'm just a user ;-)

> 4) There are smarter ways of doing this.  For example, no card will do
> well with streaming video/audio when scanning.  So perhaps
> NetworkManager should monitor the amount of traffic on the card, and if
> its above a certain level, then put off the scan.  If more than 4 scans
> (for example) have been deferred, then force a scan at the next
> interval.  This would mean far fewer interruptions.  I assume the kernel
> has some way of relaying traffic statistics to us.
not just audio streaming. i ssh a lot, and scanning time means dead
time.

> There are really just two things to consider.  We can't _never_ scan,
> and we can't always scan.  We need to find some algorithm for NM of
> balancing the two, and make that algorithm tunable on-the-fly.  We want
> to do a few scans on startup of course, to build the initial list.  And
> perhaps we want to scan more often when the card isn't in use or when
> its not associated, for example.
it seems to me that if the card is connected to an AP, it should not try to 
scan that much/often unless  the user wants it to.

> I think I've got a few ideas on how to do this, but at the moment there
> are a few other things that need to get done first...  Patches would be
> accepted though.  If you'd like to file a bug at bugzilla.gnome.org or
> bugzilla.redhat.com just to keep me reminded, that would be helpful.
> Say something like "RFE: Tuneable scanning algorithm".
done.

thanks,

Sven