Rapid DHCP: Or, how do Macs get on the network so fast? (2011)
cafbit.com
cafbit.com
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.
It's a delicate situation!
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
If this were truly about the merits and capabilities of Linux as a kernel and whichever userspace utilies you slap on, there would be no self-importance in your comments. However, it's more about showing off your accomplishments and trying to make yourself feel and seem superior.
I applaud you on your boot time. Sadly, it's not really applicable anywhere beyond the confines of your workstation.
Systemd is great and all for desktops, but I like keeping that complexity and invasiveness away from my servers.
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.
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-... 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
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.
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.
You're the kind of person who feels they're fighting the good fight and the whole world is against them, proud of having this unpopular opinion that nobody agrees with.
Yes, you're a special snowflake.
It's lame.
In 2011 Linux distros could hibernate, today they can't :-)
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.
Linux, just like MacOS or Windows, needs supported hardware to run. Since the past 8 years or so, that has meant Intel. It can be confusing that Linux "supports" every hardware under the sun, which can sometimes be true of only select versions.
Run a supported configuration and it'll "just work". My bog standard Thinkpad has suspended many times a day for the past five years and I haven't even once had a problem with it.
Intel is a joke in terms of GPUs, and absent in terms of desktop GPUs.
What you call a "supported configuration", I call "you're lucky... For now". Wait until your next distro or hardware upgrade.
That's not really a useful thing to say. Intel GPUs started out as useful only for office and programming work (still an overwhelming majority of use cases). Now it's good enough for pretty much anything that's not among the most performance demanding.
If you need a workstation with that extra performance, you probably have an application which only supports a particular configuration anyway (Nvidia on Red Hat for example, for a popular CAD/CAM tool), if which case the question isn't really relevant anyhow.
What remains are primarily consumer gaming, for which you should better stick to Windows which by far the dominating platform for it. I'm told Steam makes a difference here, so perhaps that's worth checking out, but I'm not in the industry so I have no idea about that.
> What you call a "supported configuration", I call "you're lucky... For now". Wait until your next distro or hardware upgrade.
You might be tempted to think that's so, but that's the whole idea why Linux is such a work horse on well supported hardware.
For another popular operating system, you pretty much have no guarantees that whatever drivers you require for third party support will be available in the future.
Since the well supported drivers on Linux by definition is open source, you are guaranteed (either explicitly by your support provider, or implicitly by the way development works) that it will be supported for the forseeable future. That's why I can use a ten year old printer on Linux, for example, which lost its Windows support two generations ago. Or a ten port serial board, which is probably just as old.
In the previous article, I was particularly pleased that NetworkManager is finally starting to integrate good library code rather than spawning off programs and attempting to manage them. That's half the problem with dhcpcd: it really doesn't matter how fast it is, if it doesn't actually integrate well with a broader network management system. (And on most systems I've used, NetworkManager uses and depends on dhclient instead.) I hope to see more where that came from, and it's a toss-up whether networkd or NM will integrate good library-based wireless support first.
As for RFC guidelines, as far as I know the most notable one is one that every sane DHCP client violates, namely the massive timeouts, delays, and backoffs, all written for scenarios in which a thousand systems all come up at the same time and try to get an address over a network comprised largely of tin cans and string. Those guidelines matter very little on modern networks, compared to the cumulative wait time of millions of users on millions of systems.
(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.)
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.
I wanted to say something like it, plus that most home routers do their DHCP serving with ancient versions of dnsmasq.
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.
dhcp-authoritative
no-pingThere is probably something wrong with the way I have my home network setup, but I haven't been bothered enough to dig any deeper.
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.
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).
I assume thats why it was submitted.