Re: Flush scan list on resume

[Tony Espy <espy canonical com>]

Dan Williams wrote:
> On Wed, 2009-02-04 at 15:40 -0800, Howard Chu wrote:
> > Dan Williams wrote:
> > > On Wed, 2009-02-04 at 18:04 -0500, Tony Espy wrote:
> > > > Dan Williams wrote:
> > > > > So here's why old access points show up after resume...
> > > > >
> > > > > Executive summary: exclusively a *driver* problem
> > > > >
> > > > >
> > > > > Detailed explanation:
> > > > >
> > > > > Most kernel drivers use 'jiffies' as the timestamp for each scan result.
> > > > > jiffies is a kernel counter that counts *while the kernel is alive*, and
> > > > > thus does not reflect time spent in suspend and hibernate.
> > > > >
> > > > > When the supplicant requests scan results from the driver on resume, the
> > > > > supplicant (and NM) gets back a list of scan results with recent-looking
> > > > > timestamps that do not reflect the time the machine was suspended.
> > > > >
> > > > > The solutions are to move drivers to using the actual machine clock (the
> > > > > kernel equivalent of time(2)) for last_beacon, or to be more agressive
> > > > > about expiring entries on resume with something like (10 - time spent in
> > > > > sleep).
> > OK. Having looked in my wireless-testing tree, I see that most of the drivers 
> > are now just allowing mac80211 to handle scanning, so this is not a per-driver 
> > issue. At least that makes the scope of fixing easier to manage.
> >
> > > > How 'bout getting drivers to add code to their resume functions that
> > > > just clears the scan results queue?
> > I was actually thinking it makes sense to clear results on suspend, no reason 
> > to keep kmem allocated at that point. (No point in saving an obsolete queue on 
> > a hibernate, after all.)
> >
> > > That's not desirable on mobile platforms like OLPC that do
> > > suspend/resume very quickly and very often.  The best mechanism is to
> > > make the *actual* last seen time available to the userspace programs
> > > that implement the policy (like connection managers) so they can do
> > > what's appropriate.
> > OK. I suggest a compromise then, since fetching kernel time will also be 
> > expensive if done frequently - just fetch it at driver load and resume time, 
> > and store it as a <base> in the driver. Cache entries then store base+jiffy. 
> > This allows cache stamps to continue to be cheap, but also solves the 
> > sleep/resume mismatch.
>
> Yeah, that might work.  Want to whip up a quick patch we can use for
> further discussion?

I still think simple ( ie. either have mac80211 handle the expiration or 
flush of scan results on resume ) wins out over the more complicated 
approach of having the connection manager handle expiration of older 
scan results.

Also a mobile device ( eg. a netbook or OLPC ) could be moving relative 
to the same set of access points while in S3 ( ie. within a single 
office and/or building ), and that the cached scan results after resume 
could reflect inaccurate relative signal strengths of the the APs.  This 
could effect roaming performance.

Regards,
/tony