Re: Scan while TX/RX'ing a lot of data

[Dan Williams <dcbw@redhat.com>]

On Thu, 2009-05-14 at 21:06 +0200, Johannes Berg wrote:
> On Thu, 2009-05-14 at 14:54 -0400, Dan Williams wrote:
> 
> > Libertas splits scans up into 3 parts with a short return to the
> > operating channel between each part.  There's nothing that requires
> > cfg80211 for that to work...
> 
> Yeah that was my idea too, just return to the operating channel after
> having scanned a channel or two and wait for the next beacon, and
> possibly receive traffic if indicated in that beacon. It takes a bit of
> synchronisation and isn't easy to implement, but it's definitely
> possible.
> 
> > The problem here is that at any time an application (say, wifi location
> > app) could ask for the list of access points.  If you don't scan
> > periodically, all APs other than your associated AP (and others on the
> > same channel) will gradually drop off because their beacons are
> > received.  Hard to wifi position or get area statistics if there's only
> > one AP in the list.
> 
> The other thing we should do is bump the AP list timeout, I think -- 10
> seconds is very small. But then again we really need such apps to query
> NM anyway.
> 
> > Secondarily, scanning is a tradeoff between better roaming latency and
> > continuous high throughput.  If you don't scan, you have no idea what's
> > around, and when you move and the current AP becomes marginal, you
> > *have* to take the hit no matter what, so you can scan and find a new AP
> > to associate with.
> 
> Yeah, that too.
> 
> > I would have though that the periodic scanning would be more of an
> > annoyance when doing VOIP or SSH other latency sensitive tasks, but when
> > just downloading a file, a few second drop in transfer rate gets lost in
> > the bucket in the grand scheme of things.
> 
> ssh isn't too bad, at least not after I fixed the timings... before I
> got very annoyed with ar9170. OTOH with VoIP it would suck to have a
> small hiccup every 2 minutes -- maybe then we should postpone
> indefinitely and only do it if the signal strength fluctuates?

If there was a reliable mechanism to figure out whether there was a
certain QoS level of traffic flowing through the card, this would be
easier to do automatically.  AFAIK all the APIs these days are
socket-based, and that doesn't help us get from app -> interface without
a lot of intermediate steps.  How does mac80211 figure out what to put
into each of the 4 buckets for wifi QoS / WMM?

Dan