Re: Flush scan list on resume

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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]