On Wed, Oct 20, 2010 at 7:28 AM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
On Wed, Oct 20, 2010 at 9:40 AM, Bernie Innocenti
<bernie(a)codewiz.org> wrote:
> On Wed, 2010-10-20 at 08:35 -0500, Mikus Grinbergs wrote:
>> > The question is why does it take so long for the connection to be
established?
>> >
>> > A 10-12 second reconnect time is to be expected:
>> > 1. A 1 second delay for the device to be probed and initialized on resume
>> > 2. NetworkManager has a 7 second delay hardcoded
>
> Really? That sucks!
>
> Finally explained why my simple shell script could connect in just 3
> seconds whereas NM took a lot longer.
The hardcoded sleep *is* being removed. IME, that'll first uncover a
variety of bugs and odd interactions/races in various drivers and
hardwares it has been covering for.
There is also the problem where the wireless drivers don't age network
scan results over suspend resume. The ipw2200 driver was fixed for
this issue but I don't think any other drivers followed suite. I had
written a patch for the libertas driver pre XO 1.5 release but never
tested it fully enough to say how much of a difference it made. This
does sound like it will fix the problem that has been noticed here,
where the scan list is populated and then goes away. I think the
initial list is the pre-suspend AP list that has not been aged over
the suspend cycle, so the entries still look relevant.
http://lwn.net/Articles/321102/
http://blogs.gnome.org/dcbw/2009/02/26/suspendresume-vs-networkmanager/
If people are interested in testing I can role a kernel with my
patches in it and post it somewhere.
Jon