“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.
I can get the network unavailable when waking up my Mac. I don’t have to try, it just does every time. I’m sure the author is correct that its the fastest out there, but its not that big of a deal for my usage. I have a second or two to spare.
I agree. On my Arch install it takes a little less than 5 secs. after wake up for Wicd to reconnect. And that with Broadcom driver which is not the friendliest in Linux supposedly. Works great though.
From a fresh login it’s often already up by the time I’ve entered the password and chosen the desktop, so how fast do you need it?
Yey…another “aren’t apple great’ post from Thom….this site will be Engadget v.2 before we know it
will we get another update soon on how much he loves his iPad?
To be honest – the machines that most frequently drop off our network for no reason are the apple systems – despite the face we’re running an xserve as the primary server.
Edited 2011-07-13 14:30 UTC
Oh come on, you’re not even trying! Don’t you know it’s been pass~A(c) for a while now to accuse Thom of being an Apple fanboy while trolling? These days you have to pick on his obsession with patents.
Your Xserve has zero to do with your network’s DHCP unless you’re using it as the DHCP server. And if that is the case, you’re really doing something wrong to have all your Apple machines drop. I’d take a close look at the the physical and data link layers first. I can’t count the times we’ve had a kinked cable or an accidentally unplugged switch cause havok at work. If you are still having issues after ensuring your network hardware is fine, I’d move to whatever machine (server or router) is providing DHCP and look for the problem there.
I’m curious to hear your results.
Heh. Just last night I noticed that my Mac tried to reacquire its old IP address when it woke from sleep, because a message complained, “another device is using this IP address”. In fact, the iPad was doing so. Nevertheless, the Mac quickly acquired a new address — certainly less than 11 seconds.
As for patenting this method, given the ubiquity of this need and the existence of real-time operating systems since the 70s at least, I’d wager it wouldn’t be hard to find prior art. But I’ve been wrong before.
My T42 with Ubuntu on it reconnects to a network also quite fast. Specially, when the connection is a system connection.
To be honest none of this comes as a surprise because I’ve been doing something similar for years.
I hate the lengthy DHCP process so hardcode as much info as practical into my network setting to speed this process up
Appears to be something that^aEURTMs doable and defined in a standard – albeit an RFC http://www.ietf.org/rfc/rfc4436.txt
As for the usual patent gubbins, publishing something like this arguably makes it less trollable.
I wonder is it to do with the reinitialisation of the hardware in the Mac? I’ve noticed it too, and not just with the network – many systems are much faster to return after sleeping on a Mac. One particular thing that comes to mind is the touchpad on my friend’s Vista laptop. Open it up, you can see the mouse pointer but can’t move it for a few seconds, presumably as the OS reinitialises all the connected hardware.
Since Macs have a specific set of hardware that they’re built with, maybe the initialisation process is much more streamlined (since it only expects a small number of variations), therefore reducing the time to just how long it actually takes to connect? That would explain the graphics and sound availability from very early in the booting process, and the very quick recovery from sleep.
I’d guess hardware/drivers have a lot to do with it. My older 1.3 ghz laptop’s trackpad responds as soon as I see it. Which is about two seconds after I open it from stand by.
If I understood the article correctly, the galaxy tab was connecting to a new network it hadn’t connected to before, while the mac was connecting to a known network. Because the galaxy tab had to do a dhcp discover, while the mac didn’t. Right?
Pretty much
That can’t be directly determined from the information given (currently — he seems to be updating the page a bit), but to me it looks like both devices had probably previously connected to this network, it just wasn’t the last network used. I’m assuming based on the following evidence, and the fact that the situation you suggest would hopefully be obviously uneven and flawed to the fellow doing this testing.
– Android connects, assumes it is using the last address (192.168.1.17) on the last network and tries twice to continue as such (with a ~4 second timeout) before starting from scratch.
– OS X connects, does arp queries to see if the router/dhcp server corresponds with any of the previously used (three?) addresses (192.168.2.56, 192.168.4.25, 192.168.1.29). It got a response for one of them, started normal operation with that address while also double-checking that it can actually reclaim that address in the background.
Worst-case scenario for OSX is that none of the networks is recognized and it starts from scratch. An alternative bad-case is a recognized network but the address could be reassigned (there were universities having issues with this), in which case it requests a new address and any packets sent in the interim need to be resent (it may or may not cause some arp pollution issues?). So in other words, the apple process worst-case scenario is a regular DHCP process, but it has the ability to take shortcuts if certain (probably common) criteria are met.
Back to android, the worst-case is stalling for ten seconds due to timeouts before fetching a new address. There is a shortcut only if you’re connecting to the last network only, and causing horrible delays otherwise.
This is of course just my interpretation of his data, but I think that describes the behaviour illustrated.
I don’t know, because he says,
“If the network was not recognized, I assume the Mac would know to begin the DHCP discovery phase, instead of sending blind requests for a former IP address as the Galaxy Tab does.”
The delay he is experiencing on his phone is partly due to a misconfigured dhcp server.
A dhcp server can be configured to operate in two modes, “authoritative” and “non authoritative”.
If the server was in “authoritative” mode, it would have immediately take charge of the request and told his android phone its now on a different network and it will be up to his phone to make dhcp discover request or to use the response it got from the authoritative server to notice what network is in and if the ip address it got previous is still active or not and if not.
His dhcp server is configured to be “non authoritative” and that is why it keeps quiets when it sees dhcp requests targeting another network and this silence causes his phones hang around waiting for a response wasting time before giving up and making dhcp requests.
His misconfigured dhcp server is partly to blame for the delay he is seeing
mtzmtulivu,
You may be right.
But why would a DHCP server ever be coded to ignore an IP request within it’s range?
Assuming the client went to sleep on the same lan that it wakes up on, then it’s most likely the requested IP matches the one provided by the DHCP server.
But I guess this is a good question for Thom, is the device woken up on the same network? Or did it get transported from another before being woken up?
Edit: I completely missed the context of who you were responding to….my bad, but I’ll leave the question for Thom.
Edited 2011-07-13 20:23 UTC
Good question but it is an option for a DHCP server to be authorative or not. Never had to make use of the non-authorative option but it’s there none the less.
I think the proper word is “configured”, not “coded”.
There could be a bunch of reasons, one i can think if is:
If you have a bunch of computers that have static ip addresses manually configured, you may want to tell your dhcp server not to issue those addresses to anybody and to reject anybody who ask for them
Edited 2011-07-13 20:54 UTC
mtzmtulivu,
“I think the proper word is ‘configured’, not ‘coded’.
There could be a bunch of reasons, one i can think if is:
If you have a bunch of computers that have static ip addresses manually configured, you may want to tell your dhcp server not to issue those addresses to anybody and to reject anybody who ask for them”
For one thing, static IP clients don’t use DHCP, so I don’t exactly get the logic that it has to be configured to ignore them.
Never the less, why would one ever want to configure static IP addresses in the same range as the DHCP server is handing out?
Never the less, why would one ever want to configure static IP addresses in the same range as the DHCP server is handing out?
I think we are talking over each other here since we havent really defined what we mean by “range” and i think we are using the same word but we mean two different things.
I have a dhcp server here and this is a part of what i got in its configuration file
subnet 10.10.10.0 netmask 255.255.255.0
{
option subnet-mask 255.255.255.0;
option routers 10.10.10.10;
default-lease-time 21600;
max-lease-time 43200;
option domain-name-servers 8.8.8.8;
range 10.10.10.11 10.10.10.100;
}
with this configuration file, it does not make sense to manually configure a computer with an ip address of 10.10.10.15 and i think dhcp server will complain about it if/when it notices this computer but it makes perfectly good sense to have a computer with a static address of 10.10.10.100.
When i said “range”, i meant all addresses in 10.10.10.0/24 address space. The same dhcp servers i am nanaging gives addresses on multiple interfaces running on different networks so when i said “range”, i did not mean “a range of addresses within the same network” but “all addresses in a given network address”, see the difference?
When you said “range”, i think you meant those addresses btw 10.10.10.11 and 10.10.10.20 in my configuration file. ie, a range of addresses within the same network. In this regard,you are right, it does not make sense to have static ip addresses within this range. dhcp server will probably complain about it if it finds out.
hope this clears out the misunderstanding
Edited 2011-07-13 22:51 UTC
So in other words his findings are completely null and void.
The time from discover to ACK on the tablet was .653 seconds. If it did the discover at 1.13 instead of screwing around with old addresses, it would have finished at 1.783. Fast enough that nobody would probably have ever bothered to test. It’s also fast enough to probably void any gains by skipping that when you’re on the same network, so I suggest skipping to “Maybe this is a different network” step by default.
It takes me longer than 1.75 seconds to go from opening laptop to password input and desktop reached anyways.
his phone spent the majority of the time waiting for a response from the dhcp server when it asked for an address because it asked for an address that exists outside the network address the dhcp server is responsible for and the server ignored him and it took a while for his phone to realize it was being ignored and it sent a dhcp discover request and the server responded to it as it should.
This behavior is an expected behavior of a “non authoritative” dhcp server. If he doesnt like the delay, then he should reconfigure the dhcp server if he can and make it an authoritative one.
His result would have been interesting if he tested it on a properly configured dhcp server or if he can show that the majority of routers out there use a non authoritative dhcp server.
Awesome, but depending on the router the Mac gets the “hey I’ll give you a private address as I do not like this DHCP stuff here…” issue or you have to keep pinging the router regularly else it will drop the connection (say every 5-10 or more seconds just to be safe
).
Same MacBook Pro, booting Windows 7, no network issues at all on the same network.
Still, networking on MacOS X is quite nice, I have to admit that
.
You say that, but my mac takes forever if it loses WIFI connection while still up. It will just spin while my phone and Ubuntu computer are both back up (say, after a router reboot). It may be fast coming back after suspend, but I spend a couple seconds on OSX and Ubuntu putting in my password to get back in anyway, so I really don’t see a delay on ubuntu. (I have no experience with Windows post XP and WIFI)
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
and that mostly depends on your network setup. it takes 1.5 sec on wireless and <1sec on wired for me in fedora on any machine i try. as far as i see, dhcpclient will need >10sec only when you didn’t set up everything as it should be on dhcp server.
about first package, you can simply simulate what you say by unplugging and requesting ip, then plug back asap. time frame will be drastically slower because it waits long time until second request is made.
I’d just be happy to get a linux laptop that could wake up from sleep.
I used to wait for many seconds to get network connectivity (via Wi-Fi) after waking up my Windows 7 laptop and that, not counting the time taken to enter the password to unlock the computer. That was when I was using the Wi-Fi driver from Windows Update. After switching to the Wi-Fi driver downloaded from Intel’s website, the laptop wakes up and I have network connectivity almost immediately.
Please, allow me to correct what the article says. When Windows starts, it takes a long time for the computer to lease a client from DHCP because the process is done after booting. In apple that process is done while booting same as in Linux. However, Linux is faster because Linux has less overhead than Apple. In the end for those of you who know Linux and Apple. Apple is just a beautified version of Linux because both are Unix based.
Hi,
Is there potential race condition/s in MacBook Pro’s network initialisation?
As far as I know, until the “DHCP ACK” is received the old lease could expire at exactly the wrong time (e.g. immediately after the last “ARP reply unicast” is received by the client) and be reassigned to a different client by the DHCP server; and the Mac could end up using an IP address that belongs to something else (in rare cases of bad luck).
Based on the times in the article, a “DHCP discover”, “DHCP offer”, “DHCP request” and “DHCP ACK” sequence would’ve taken 653 ms and could’ve began 10 ms after the link is established (and you’d be able to use the MAC from the “DHCP ACK” to determine if you’re on the same network as last time anyway).
– Brendan
I installed Fedora 15 on my Samsung 9 laptop.
My Macbook gets an IPv4 and IPv6 address before I can finish opening the lid.
Fedora’s NetworkManager takes 15 seconds.
Yes, I have authoritative; set in the dhcpd.conf on the Linux router. I’m using radvd for IPv6 autoconfig.
Honestly, 15 seconds is pretty crap.
This may be too much to ask, but I’d like to look at a wireshark dump of the traffic from an external interface.
That would give a fairly definitive answer to the question of “why” it’s taking so long.
Of course things should just work. If I am right about the client just sitting there waiting to send the next packet, well the DHCP spec is at fault. A non-compliant implementation wouldn’t have to wait so long before retries.
On my home router, here are the dhclient sequences.
// no pre-existing IP leases
0.0s execute dhclient
3.0s dhclient sends DHCP Discover
3.5s router responds with DHCP Offer
3.5s dhclient sends DHCP Request
3.5s router responds with DHCP ACK
I repeated this 3 times, same results. I find it very odd that the first packet isn’t transmitted immediately. Maybe the dhclient guys deliberately delayed the first packet to give the network time to settle, but an arbitrary delay could conceivably cause race conditions which are exacerbated by wifi.
// pre-existing IP lease
0.0s execute dhclient
3.0s DHCP Request
3.0s DHCP Ack
This looks totally normal, the 3s delay served no purpose here, but the DHCP server acked immediately.
// cold start, no DHCP server
3.0s DHCP Discover.
11.0 DHCP Discover
23.0s DHCP Discover
30.0s DHCP Discover
45.0s DHCP Discover
55.0s DHCP Discover
So assuming the Wifi hasn’t connected within 3s (which seems plausible from a cold start as opposed to merely a standby mode), the dhclient (using default ubuntu settings) won’t even try again until 11s.
This could very well be Thom’s problem.
Rephrased…
How does my: 2.3 GHz 4 GB Ram
Compare to my: 1.5 GHz, 1 GB Ram
Any Questions?
i just went from pc to mac. and i have noticed a good decrease in ping rates. even on wireless. mac’s network stack must be more efficient.
How can you even compare software on two different sets of hardware? Your PC is probably a non-brand one, is at least two times cheaper than your Mac, and has a pair of crappy Realtek NICs with a driver disk from 2004 and no driver updates released via Windows Update. Are any OS updates installed at all? Oh, wait… Are we talking Vista here? ))
p.s. Care to provide network traces? ICMP pings are too trivial for network stack efficiency to manifest itself. Normally it is compared by bulk TCP transfers, number of packets/connections processed in a fixed amount of CPU time, etc.
Edited 2011-07-15 22:20 UTC
static666,
“How can you even compare software on two different sets of hardware? Your PC is probably a non-brand one, is at least two times cheaper than your Mac, and ”
A “good decrease in ping rates” is extremely vague to me also. Ping is hardly a sufficient benchmark for comparing network stacks. From my 3GHz core2 under linux (a couple years old), I get <1ms pings to my router. It hardly says anything about how well it performs under real world loads.
If I had a mac pc, I’d compile the same benchmark under macos and linux, and then dual boot to compare the difference. But since I don’t, I have to take other people at their word.
Edited 2011-07-16 02:08 UTC