
Rapid DHCP: Or, how do Macs get on the network so fast? (2011) - JoshTriplett
http://cafbit.com/entry/rapid_dhcp_or_how_do#
======
guylhem
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.

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

~~~
revisionzero
More than just a 'bit'.

~~~
guylhem
Indeed, I'm very pompous since I'm quite proud of what a modern linux install
can do.

Sorry if I don't partake in this unwarranted Mac adoration.

Instead, I explain how to do the same on linux, and actual results when it's
possible to do better (with among other things i915.fastboot=1)

$ systemd-analyze

Startup finished in 781ms (kernel) + 648ms (userspace) = 1.430s

Add ~1s to the above to start X with SNA if you prefer a graphic mode - and
that's on a 2006-era laptop, a 8-years old machine, so color me unimpressed.
[http://en.wikipedia.org/wiki/ThinkPad_X_Series#X60_Tablet](http://en.wikipedia.org/wiki/ThinkPad_X_Series#X60_Tablet)

~~~
PhasmaFelis
You despise "fanboys" and "adoration," but you're "proud" of an OS that (I'm
guessing) you had nothing to do with the development of?

This, right here, is the problem. People choosing to attach their personal and
tribal identity to an operating system. It doesn't matter what operating
system it is, or how good it is. It's no more noble than doing the same thing
with a football team or a comic book character.

~~~
guylhem
You're guessing wrong, even if I'm less involved in free software that I was a
few years ago.

But indeed, I'm quite passionate about GNU/Linux and say the gluglug X60 since
it's a unique offering to respect ones' freedoms:
[http://www.fsf.org/news/gluglug-x60-laptop-now-certified-
to-...](http://www.fsf.org/news/gluglug-x60-laptop-now-certified-to-respect-
your-freedom) but I'm actively trying to improve boottime.

In case you are curious, here's a kernel patch integrating a few things I
(badly) fixed to get such boot times, and an explanation:
[http://comments.gmane.org/gmane.linux.bios/80414](http://comments.gmane.org/gmane.linux.bios/80414)

You see, it's a very small patch - yet it took some work. There's no magic,
just effort.

And for those who think that's not replicable anywhere beyond the confines of
my workstation, I intend to release very soon a debian based distribution with
"proper" systemd support that gets me from grub to dwm in less than 2 seconds
instead of 3s, kernel and systemd time included, on the X60 (I had some
inspiration tonight!!)

It's a work-in-progress, it could be improved on the non-tablet version, but
it's still something that's possible _right now_ on _8-years old hardware_.
That's what I call hacking.

For me, free software is not a tribal identity. It's very practical, with
great benefits far beyond fast boot times.

Things change because people work on them, and yes they're usually proud of
their work, sorry about that. Pride is part of hacking.

I must say I have been quite surprised by the general tone of this thread,
including the ad-hominem attacks ("Seems he is working for Intel on CoreOS")
on the OP that was trying to explain stuff. Many people don't post content,
they just criticize.

~~~
PhasmaFelis
That's good that you're contributing to free software. I _like_ free software,
you understand. But your sneering at "fanboys," your acting like someone's
choice of operating system is a moral stance rather than a matter of
convenience and personal preference, still says that you are not being as
rational as you think you are. Only fanboys accuse people of being fanboys.
Your choice to use free software may not be a tribal identity, but your choice
to mock people who don't absolutely is.

~~~
ginko
>acting like someone's choice of operating system is a moral stance

It certainly is when you pick a free software/open source OS over a
proprietary one.

~~~
PhasmaFelis
> _It certainly is when you pick a free software /open source OS over a
> proprietary one._

A whole lot of people have convinced themselves that it is, at least. I'm not
quite ready to accept that using the wrong operating system makes you a bad
person. I'm kind of amazed that I even have to say that.

------
lunixbochs
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.

~~~
xorcist
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.

~~~
lunixbochs
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

------
sleepydog
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
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
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?

~~~
Booktrope
Same experience here with a MacBook Pro circa 2012. Often seems slow to re-
establish network connection after sleep. I've seen this on a variety of
networks. Really just an annoyance, but better management of this on my Mac
would be nice.

~~~
peteretep
Go in to Network Prefs, and get to the list of known networks. Drag the ones
you use often to the top.

~~~
mgkimsal
it'd be nicer if that list of known networks was, say, searchable, sortable
and perhaps even, who knows, taller so I could see more than a handful at a
time. It seems like it's written for people that connect to 4 networks and
never move around.

------
mmastrac
Previous discussion from 2011:
[https://news.ycombinator.com/item?id=2755461](https://news.ycombinator.com/item?id=2755461)

------
hollerith
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.

~~~
devindotcom
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
If you're talking about OS X, You can change the password in the keychain, or
forget the network via the Network prefpane.

~~~
ericd
Yeah, I've never had problems with just changing it via the keychain. Also,
manually connecting after it fails to connect causes it to prompt me for the
password.

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

[https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8](https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8)

------
nextos
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
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/](http://electricimp.com/)

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

------
digi_owl
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
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.

