On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote:
This likely isn't any desktop component that is causing this, but
like to know what it is that makes getting back on wireless network
after resuming from suspend take so long. I've bee comparing with Vista
on my laptop just for giggles, and Vista is back on the wireless and FF
even refreshes my gmail before I can get my password typed into the
screen lock. This is all very very very fast. F9 on the other hand
takes longer to get to the password dialog and then once unlocked it can
still be another minute+ before NM starts the connection dance, another
30 seconds after that before wireless picks up again. Where is the
NM throws away the current access point list on suspend/hibernate. On
resume from sleep/hibernate, it needs to do a scan or two to find the
network to associate with, and after that, do the whole connection
process (including DHCP) again. There is a considerable amount of lag
here, and there's certainly room for improvement.
First, we need better kernel interfaces for wireless. Finishing
nl80211/cfg80211 and ensuring that they have a more request/response
oriented API  is the way to go.
Second, Mac OS X and Windows indicate connection differently from
NetworkManager. Mac OS X will show that Airport is "connected" way
before it's successfully completed DHCP or IP assignment. That's a
completely useless status since you can't actually do anything in that
state, so NetworkManager considers the "connected" state to be once all
IP configuration is complete and successful.
Third, drivers still suck for scanning. Ideally, we'd just fire off a
quick scan right after NM wakes back up, get back a nice list of access
points, and immediately connect to one of them. For whatever reason a
single scan is still not reliable enough to get an adequate picture of
the network around you. And since scans can take quite a bit of time to
complete  you get unacceptable latency here.
So how to fix this?
a) Get drivers to support specific SSID scanning (unfortunately older
drivers probably won't be able to do this, but all mac80211 drivers
can), and when an SSID scan is requested, make that jump to the start of
the scan queue. Have the driver/mac80211 provide a specific response to
that scan request so that NetworkManager knows the result.
b) When coming out of sleep, have NetworkManager SSID scan the last
connected AP. If that AP doesn't show up in scan results (its not
there, the driver sucks, etc), continue as normal. If that AP does show
up in scan results, try to associate with that AP.
c) Since NM controls the DHCP client, NM is capable of providing
different lease files to dhclient for each network you've connected to.
So for 'my-home-wireless' NM could try to re-acquire the previous lease
before falling back to a complete DHCP transaction.
I don't really know how much time this would save, since lots of the
latency is in the wpa_supplicant <-> driver communication during
authentication/association because the WEXT API is so bad at reporting
it's status. But that can be improved independently of the NM bits, and
the stuff above is definitely a win.
Try resuming while plugged into a cable, and NM will be REALLY FAST.
It's just when you throw wireless into the mix that stuff gets more
complicated and therefore quite a bit laggier.
 i.e. a way to track the result of specific requests. With WEXT you
say "associate to X" and some time later the driver may or may not send
association status back, but there's no ID/cookie to tie that result
back to the original request that was made. Would be nice to be able to
track the progress of asynchronous operations through the driver/kernel.
 historically up to 10s with madwifi to scan both A and B/G bands;
you have up to 60 channels with at least a 100ms passive scan dwell time
on each channel, and maybe 50ms channel switch lag, not including
firmware/driver command latency. SSID scanning (called an "active scan"
in 802.11) helps because you send out the probe request and only have to
wait 20 or 30ms before giving up, instead of the minimum 100ms a passive