Rapid DHCP: Or, how do Macs get on the network so fast? (2011)

http://cafbit.com/entry/rapid_dhcp_or_how_do#

by JoshTriplett • 12 years ago

82 56 12 years ago

mmastrac• 12 years ago

Previous discussion from 2011: https://news.ycombinator.com/item?id=2755461

sleepydog• 12 years ago

This has not been my experience; after resuming my macbook, it takes up to 30 seconds for it to reconnect to my home network. It is much faster if, after resuming, I disable and re-enable WiFi.

There is probably something wrong with the way I have my home network setup, but I haven't been bothered enough to dig any deeper.

chc• 12 years ago

Mine is slower than reported too. My circa-2010 MacBook Pro takes 10-20 seconds on my home network, whereas the 2014 MacBook Pro I'm using right now takes about one second on the same network. I had suspected it was just the newer hardware being better, but this story is from 2011 and they were already seeing one-second connections back then, so I'm not sure what does it.

vitd• 12 years ago

I notice that when I return from work, it often takes 10-20 seconds as you say, but when I have been at home for a few days, it seems to take only a second. Maybe it's related to how long you've been using the current network or something?

ollysb• 12 years ago

My macbook pro(late 2013) consistently fails to connect to the wifi on it's first attempt and never connects in under 20seconds. It was a similar story on my previous macbook air as well. Note this is consistent with different laptops, different networks and different versions of the OS.

hollerith• 12 years ago

I'd rather my Mac were more reliable about getting on the net -- or if failures to do so were easier to fix and to understand.

Sometimes it takes fussing around (e.g., rebooting the cable modem, telling the Mac to try again to connect) to get on the net, and this time spent fussing around never seems to leads to an insight that would help the next time I need to fuss around.

It is a small thing, but this is one aspect of "client computing" where I would probably prefer the Linux way of doing things in which it is more tedious to do simple things, but when something goes wrong, it is easier to understand the problem.

devindotcom2• 12 years ago

Yeah, just yesterday I went to a local cafe and they'd changed the wireless password. I had to search online for a way to change the current password for a remembered wireless network! Turns out there's no way really, you have to run this wireless wizard thing and input the password that way. What?!

jhgg• 12 years ago

If you're talking about OS X, You can change the password in the keychain, or forget the network via the Network prefpane.

guylhem3• 12 years ago

That's at least the 3rd time I see that article posted here!!!! It's NOT exceptional or some special kind of wizardry. Even NetworkManager now does that.

If you have an old setup, you can get matching speeds with dhcpcd and the following options added to the bottom of debian /etc/dhcpcd.conf:

ipv6rs #ipv6ra_own #ipv4only noipv4ll noarp

The latest 2 options are the helpful ones for speed. The rest is for my IPv6 setup - can't remember if the Macs give you a dhcpv6 lease that fast.

Since it's bragging time, my debian+systemd thinkpad x60 laptop using coreboot want to say it resumes from suspend in about 1 second, and it boots its kernel in 0.7s and the userspace tools in 0.5s (add another second for X thanks to SNA, and another second for LXDE/conky/etc.)

What is the boot time for mac already?

EDIT: linux laptops properly resuming is still impressive for me as I remember a time not so long ago when one had to use some kernel patches, tweak the drivers or at least do a few rmmod, and even then a proper resume could take several seconds due to the drivers reinitializing.

Linux has come a long way since them. What might have been surprising before is now taken for granted (as it should be!).

EDIT2: I see downvotes. I guess some fanboy is quite sad that linux can do the same or better.

frozenport2• 12 years ago

>Linux has come a long way since them.

In 2011 Linux distros could hibernate, today they can't :-)

guiambros3• 12 years ago

I simply can't get Ubuntu 14.04 to hibernate and resume reliably. 1 out of 10 times it's dead on resume. The culprit seems to be fglrx (as usual), but no decent solution other than to give up on AMD and go back to Nvidia (not gonna happen).

We've come a long way since the first Slackware, but Linux on the desktop is still a hot mess, particularly in terms of WM. I sincerely wish we had less options, and some of the "it just works" from Macs.

JoshTriplett3• 12 years ago

Personally, I posted this because Linux can now DHCP far faster, with both systemd-networkd and NetworkManager, and I thought people might find it interesting to read about some of the techniques used to speed up DHCP.

vezzy-fnord2• 12 years ago

You wrote this in a previous thread as well, but never responded to my comment then. I have no idea why you are hyping up networkd's DHCP client so much, given that it was established that a) its functionality is a small subset of dhcpcd and dhclient, b) dhcpcd could reach comparable speeds provided additional steps unsupported by networkd like ARP checking are disabled and c) networkd DHCP violates and/or sidesteps RFC guidelines.

TheSwordsman3• 12 years ago

No, let's not kid ourselves. You're being downvoted for being a bit pompous.

revisionzero• 12 years ago

More than just a 'bit'.

zanny• 12 years ago

On my machine (its a 4770k + Asus mobo) I boot to desktop on Arch + KDE before all my monitors power on.

techrat• 12 years ago

My Chromebook turned xUbuntu system is already back online before the screen turns back on after opening the lid. All of the Macs we use in the studio are much slower than that.

digi_owl4• 12 years ago

I guess MS have been slacking in their back room lock-in, or Linux have gotten better at faking Windows-isms in front ACPI etc.

PhasmaFelis4• 12 years ago

So (in this particular arena) Linux can, by Googling around and digging into conf files, match the speed that a Mac has out of the box? That's nice, but it's not exactly impressive. Why isn't it configured that way to start with?

(My personal machines are a Mac laptop, a Windows desktop, and a Linux server. I have no dog in this fight. I kind of don't understand why people think they do have a dog in this fight.)

Tobu2• 12 years ago

It's standard, Linux distributions generally install NetworkManager. The tweaks are for people who want more control or have less typical setups.

nextos• 12 years ago

Connman, used by many mobile Linux distros, achieves this even quicker. AFAIK, Jolla uses it. So do I in Arch, and it's wonderful.

jonemo• 12 years ago

This might be true for connecting to a wired network, but like others stated in this thread, Macs can take a surprisingly long time to connect to a wireless network.

If you want to see a client connect to Wifi very fast, check out the electricImp [0] module. I've never seen mine take longer than two seconds to go from power-on to it being registered with the server (EC2 instance).

[0] http://electricimp.com/

LeoPanthera• 12 years ago

The article specifically mentions that the Mac is connecting over wi-fi, several times, and gives a connection time of 1.3s.

digi_owl4• 12 years ago

Don't get it. Unless the wifi hardware fails to initialize i have never found Android to be a slow connector. Are we so stuffed with stimulants these days that we can't handle those seconds?

droopyEyelids• 12 years ago

Before it was a marketing term, "Hacker" meant someone who tried to understand things at a deep level, and pushed that understanding into new techniques, uses, and better performance.

I assume thats why it was submitted.

lunixbochs2• 12 years ago

In my pretty extensive tests, a long initial lease time is almost always the DHCP server's fault. I didn't see really any time wasted in DHCP REQUEST in my tests across many devices and operating systems. I think setting your DHCP server to authoritative will usually cause it to do a DHCP NACK in response to a bogus DHCP REQUEST, which prevents any delay there as observed in the article.

I measured lease time when connecting a client as "time from DHCP DISCOVER to DHCP ACK", which I found effectively represents the time between a device connecting to WiFi and being available on the network with an IP address.

With stock dnsmasq, the shortest "new connection" lease time I observed on an uncongested network was around five seconds. Almost all of the time was spent waiting for the DHCP server to respond.

With a modified dnsmasq, the shortest time to lease I observed was 20ms. That was also the longest time to lease on every platform I tested except iOS, which spends about a second trying to ICMP ping the IP address before it takes it. On iOS devices, the time to lease was almost always exactly 1s20ms the first time, and about 20ms on subsequent attempts with the same device.

You can do the same tests yourself by sitting on a wireless network with Wireshark and connecting with a device that has had the network forcibly "forgotten". Mark the first DHCP DISCOVER packet you see, and set the timestamps to relative. Filter the traffic to just show the MAC address of the router and connecting device, then look for the DHCP ACK from the router.

xorcist3• 12 years ago

Wish I could upvote more.

I wanted to say something like it, plus that most home routers do their DHCP serving with ancient versions of dnsmasq.

lunixbochs2• 12 years ago

It's still a problem with the latest version of dnsmasq. Look for `if ((count < max) && !option_bool(OPT_NO_PING) && icmp_ping(addr))` in `src/dhcp.c`. Most of your lease acquire time is spent in `icmp_ping()` which actually just sends ARP requests for 3+ seconds then gives up. It's actually not even very reliable when someone is using the IP already, because many devices won't respond to ICMP.

There's an option to disable it (OPT_NO_PING) which does improve lease performance with pretty much no downside (as ICMP is a flawed way to check if an address is in use anyway).

  -5, --no-ping (IPv4 only)
  By default, the DHCP server will attempt to ensure
  that an address in not in use before allocating it
  to a host. It does this by sending an ICMP
  echo request (aka "ping") to the address in question.
  If it gets a reply, then the address must already be
  in use, and another is tried. This flag disables
  this check. Use with caution.

So, if you're configuring dnsmasq, these flags will give you some nice performance gains:

  dhcp-authoritative
  no-ping

Tobu2• 12 years ago

Dated. DHCP can be done in milliseconds, 50ms over a WiFi connection:

https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8

Rapid DHCP: Or, how do Macs get on the network so fast? (2011)

Related Stories