Linked by Thom Holwerda on Wed 13th Jul 2011 14:09 UTC
Internet & Networking "One of life's minor annoyances is having to wait on my devices to connect to the network after I wake them from sleep. All too often, I'll open the lid on my EeePC netbook, enter a web address, and get the dreaded 'This webpage is not available' message because the machine is still working on connecting to my Wi-Fi network. On some occasions, I have to twiddle my thumbs for as long as 10-15 seconds before the network is ready to be used. The frustrating thing is that I know it doesn't have to be this way. I know this because I have a Mac. When I open the lid of my MacBook Pro, it connects to the network nearly instantaneously. In fact, no matter how fast I am, the network comes up before I can even try to load a web page. My curiosity got the better of me, and I set out to investigate how Macs are able to connect to the network so quickly, and how the network connect time in other operating systems could be improved." Yes, I'd love to have Windows and Linux reconnect as fast as Macs do. Alas, "Method to quickly reconnect to a wireless or wired network", as well as its completely different "Method to quickly reconnect to a wireless or wired network on a mobile device" are probably patented, so Windows and Linux can't reconnect too fast out of fear of violating a software patent. In case you haven't noticed: I'm joking. Sort of.
Permalink for comment 480769
To read all comments associated with this story, please click here.
DHCP spec
by Alfman on Wed 13th Jul 2011 18:25 UTC
Member since:

In my experience is that DHCP is immediate so long as the first packet is successful. However on startup, the initial DHCP packets do fail to reach the network (maybe it's a bug or things haven't been initialized yet, I don't know).

This would be perfectly ok if DHCP kept retrying quickly, however the DHCP code in linux and I presume windows is VERY UNAGGRESSIVE and spends a great deal of time sitting in backoff mode.

The DHCP spec itself mandates a specific exponential backoff algorithm. If the hardware isn't ready to handle the first packet. The client sends a 2nd packet at 4 seconds plus random time. If the network still isn't ready, then the spec mandates that DHCP wait another 8 seconds before retrying. If packet loss occurs here, then the spec mandates another 16 second delay, etc.

A transit packet loss issue is purely coincidental, if you have a problem every single time you start up, then it is likely a systemic problem due to network hardware not being ready to transmit yet.

Ironically, sleeping for a few seconds before invoking dhclient could help the chances of the first packet responding immediately and preventing too early backoff. You might try changing the backoff-cutoff time in dhclient.conf. The man page says the default is 2 minutes. Unfortunately the problem has more to do with the backoff ratio during startup, but this is hard coded to 2. Ideally you could change the ratio or defer backoff for the first few seconds.

I am just speculating what your problem could be, but you'd really have to stick a probe on the lan/wifi and watch the network traffic to actually see what's going on. Let us know what you find out!

I'd be curious to know whether the mac follows the algorithm in the DHCP spec.

Edited 2011-07-13 18:30 UTC

Reply Score: 3