Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Desktop (http://www.linux-archive.org/fedora-desktop/)
-   -   Slowness getting back on network from resume (http://www.linux-archive.org/fedora-desktop/124523-slowness-getting-back-network-resume.html)

Jesse Keating 07-14-2008 02:51 PM

Slowness getting back on network from resume
 
This likely isn't any desktop component that is causing this, but I'd
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
delay?

--
Jesse Keating
Fedora -- Freedomē is a feature!
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

seth vidal 07-14-2008 02:52 PM

Slowness getting back on network from resume
 
On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote:
> This likely isn't any desktop component that is causing this, but I'd
> 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
> delay?
>

Which card and which kernel? I noticed really slow to never pick up
times on the iwl4965 on -86 kernel.

-sv


--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

"Paul W. Frields" 07-14-2008 02:59 PM

Slowness getting back on network from resume
 
On Mon, 2008-07-14 at 10:52 -0400, seth vidal wrote:
> On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote:
> > This likely isn't any desktop component that is causing this, but I'd
> > 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
> > delay?
> >
>
> Which card and which kernel? I noticed really slow to never pick up
> times on the iwl4965 on -86 kernel.

Same result here, 2.6.25.9-76.fc9 and iwl3945.
.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

Jesse Keating 07-14-2008 03:00 PM

Slowness getting back on network from resume
 
On Mon, 2008-07-14 at 10:52 -0400, seth vidal wrote:
>
> Which card and which kernel? I noticed really slow to never pick up
> times on the iwl4965 on -86 kernel.

4965, any kernel I've thrown at it that actually has working wireless
drivers.

--
Jesse Keating
Fedora -- Freedomē is a feature!
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

Bill Nottingham 07-14-2008 03:08 PM

Slowness getting back on network from resume
 
Jesse Keating (jkeating@redhat.com) said:
> This likely isn't any desktop component that is causing this, but I'd
> 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
> delay?

Is Windows caching the IP & scan information across suspend/resume?

Bill

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

Jesse Keating 07-14-2008 07:07 PM

Slowness getting back on network from resume
 
On Mon, 2008-07-14 at 11:08 -0400, Bill Nottingham wrote:
> Jesse Keating (jkeating@redhat.com) said:
> > This likely isn't any desktop component that is causing this, but I'd
> > 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
> > delay?
>
> Is Windows caching the IP & scan information across suspend/resume?
>
> Bill

It's entirely possible. It seems awfully fast. I haven't yet tried
moving to a different area / access point between suspends to see how it
handles that.

--
Jesse Keating
Fedora -- Freedomē is a feature!
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

"Jon Stanley" 07-14-2008 07:47 PM

Slowness getting back on network from resume
 
On Mon, Jul 14, 2008 at 11:08 AM, Bill Nottingham <notting@redhat.com> wrote:

> Is Windows caching the IP & scan information across suspend/resume?

I'm required to use a Windows laptop for $DAYJOB, and I noticed the
same, fast, behavior when going from the office (wired network) to
wireless at home. I've not done any actual speed comparisons, nor can
I do so today (working from home due to my bum shoulder for
awhile....)

I also notice my Windows machine can be slow as a dog, thrashing the
hard disk, and I have no tools to diagnose that like I would on Fedora
(my first guess is the stupid antivirus). You win some, you lose some
:)

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

Dan Williams 07-15-2008 03:40 PM

Slowness getting back on network from resume
 
On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote:
> This likely isn't any desktop component that is causing this, but I'd
> 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
> delay?

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 [1] 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 [2] 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.

Dan

[1] 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.

[2] 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
scan requires.

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

Jesse Keating 07-15-2008 04:02 PM

Slowness getting back on network from resume
 
On Tue, 2008-07-15 at 11:40 -0400, Dan Williams wrote:
>
> 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.

I wouldn't lump Windows in here necessarily. As I stated in my mail
that by the time I clear the screen lock, not only is the wireless
connected, but it's actually communicating with the Internet, enough to
get my gmail refreshed.

The rest of the info is good, this feels like fit/polish that could go a
long way either for the good, or if left along go a long way for the
bad.

--
Jesse Keating
Fedora -- Freedomē is a feature!
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list


All times are GMT. The time now is 02:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.