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:
- A 1 second delay for the device to be probed and initialized on resume
- NetworkManager has a 7 second delay hardcoded
- A 1-2 second delay for scanning to complete
- A 1-2 second delay for authentication, association, key exchange
(if applicable) and DHCP.
It has looked to me as though icons already in Neighborhood View can disappear as the XO reinitializes a complete scan of its radio spectrum.
I still think that in the plurality of wireless startup cases the pupil will expect to make a connection on the SAME frequency that the XO was using the last time his XO system's wireless was in use.
[I hope that an XO which is in "I've had my wireless connected for a whole hour" mode can nevertheless detect whenever a __new__ AP shows up (whose radio signal was not previously noticed). If that is possible, then the SAME capability should be applicable even at startup time.]
I'm thinking that at startup, Network Manager ought to be *inhibited* while the XO listens on the same frequency as was last used. If the XO hears a strong enough signal, it ought to go into its "I've had my wireless connected for a whole hour" mode -- and depend upon "radio signal discovery" the same way that it does when not starting up..
Only if the XO at startup does NOT hear a strong signal on the last-used frequency should the XO depend upon scanning and Network Manager to determine "what are the radio signals that I am receiving now". Whenever steps 2-3 above can be avoided, wireless startup will be noticeably quicker.
[For those cases where the pupil has moved to a different schoolroom while his XO was powered down - once the XO is powered up let the pupil perform whatever manual "tuning" procedure he would have used if he had moved to that different schoolroom while carrying his XO powered up.]
mikus
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:
- A 1 second delay for the device to be probed and initialized on resume
- 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.
[I hope that an XO which is in "I've had my wireless connected for a whole hour" mode can nevertheless detect whenever a __new__ AP shows up (whose radio signal was not previously noticed). If that is possible, then the SAME capability should be applicable even at startup time.]
This is called background scanning. Most wifi firmwares do it because it's required to hop to another with the same ESSID and better signal quality.
Background scanning may introduce several ms of latency while the radio is switching channels. Gamers know tricks to disable it.
On Wed, Oct 20, 2010 at 9:40 AM, Bernie Innocenti bernie@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.
Only once we're past that fallout, with those bugs accounted for and fixed, we might get better behaviour. In the meantime. suckitude in this area is likely to increase :-[
ain't optimism great?
m
On Wed, Oct 20, 2010 at 7:28 AM, Martin Langhoff martin.langhoff@gmail.com wrote:
On Wed, Oct 20, 2010 at 9:40 AM, Bernie Innocenti bernie@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
On 20 October 2010 15:28, Martin Langhoff martin.langhoff@gmail.com wrote:
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.
It wasn't a workaround for races or bugs. It was a fundamental part of the NM user vs system split. If you remove it, you'll break things like ethernet connectivity. Not because of bugs, just because having a delay was an inherent part of the "who gets it" design, mostly thanks to limitations of HAL.
This has already been solved better in newer versions of NetworkManager, thanks to advancements in udev allowing for nicer NM design/interactions.
Daniel
On Wed, 2010-10-20 at 10:28 -0400, Martin Langhoff wrote:
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.
I'm hitting one of these races even *with* the hard-coded timeout: it's between wpa_supplicant and NetworkManager, on resume from suspend. It causes the list of available access points to remain blank.
Dan Williams helped me analyze the issue, but we still have no fix.
-
Bernie Innocenti -
Daniel Drake -
Jon Nettleton -
Martin Langhoff -
Mikus Grinbergs