Live data from Hacker News

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

cafbit.com

101–110 of 114 posts

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

#101
post #96

This is an article from 2011, 6 years ago. Has there been any progress on implementing RFC 4436 on Linux in general or Android specifically in the interim? http://www.ietf.org/rfc/rfc4436.txt

TL;DR: ChromeOS uses this rfc, Android, dhcpcd, isc-dhcp-client doesn't (Note: I have no clue about systemd-networkd) Ok, so the article covers ARP discover, but actually it's not the only issue. The author mentions a 10s timeout because his DHCP is not authoritative. But in my opinion, that's not the real problem (though I admit it is better if his setup has it). The author's device should not ask for an unrelated I…

Awesome work!

Also, You not working for Google just proves their headhunting and recruitment process is not worth shit

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

#102
post #74

Earlier quoted context omitted.

Unless your DHCP server is an old Commodore 64, that's not the right diagnosis. The ISC DHCP server was rock solid with negligible CPU load with many thousands of clients even 10-15 years ago. If your network is really having problems, either dig deeper if you want to learn more about networking or buy something like a Google WiFi device if you just want something known to handle much greater loads without issue.

It will kill my fiber to the home network box that my telco installed, and provides DHCP. It isn't a load issue, it is a "the DHCP server died" issue.

That's a bug in that software stack which is unique to however they've designed it. The right thing to do is fix it or replace it rather than blaming the vendor you notice problems with, just as you wouldn't blame a pothole on the first car to hit it.

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

#103
post #100
post #92

Earlier quoted context omitted.

It's better but definitely not "extremely fast". The mac from 6 years ago does it in 300ms which is still 3-10x faster than what you suggest is the norm for your setup. The difference between 300ms and 3 seconds is the tipping point for being annoyed when you cannot connect to the first page you visit.

You misunderstood my numbers :) Search "chromebook boot time" on YouTube. Checkout the comparisons between a $200 chromebook from 2013 and a $2000 MBP...

ChromeOS is not a real OS. It's an embedded appliance/cloud OS as a gateway to the web and Google services. Anyone can make a machine boot fast if it has nothing to load.

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

#104
post #103
post #100

Earlier quoted context omitted.

You misunderstood my numbers :) Search "chromebook boot time" on YouTube. Checkout the comparisons between a $200 chromebook from 2013 and a $2000 MBP...

ChromeOS is not a real OS. It's an embedded appliance/cloud OS as a gateway to the web and Google services. Anyone can make a machine boot fast if it has nothing to load.

Just because it's not bloated doesn't make it any less of an OS then any other minimal Linux installation, it is itself built on the Linux kernel - it is just highly optimised for a very select set of software and hardware requirements.

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

#105
post #91

Earlier quoted context omitted.

Neither Windows nor Linux desktops buck the trends (with respect to documentation and user expectations) that their server counterparts follow.

And dump truck gearing patterns are kind of similar to manual transmission car patterns. Complaints about the difficulty of driving a dump truck remains irrelevant to cars.

"Kind of similar" is very different from "arranged by the same people following the same processes with many packages being identical". We're talking about comparing transmissions from the same manufacturers with a lot of shared parts.

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

#106

I remember this feature used to cause a lot of problems with random IP conflicts, but I haven't had an IP conflict like that in years, so it seems they've made it a lot more robust. Or are routers/DHCP servers just less broken these days (I guess since Apple's market share has forced them to)?

Circa 2014:

https://www.net.princeton.edu/apple-ios/ipad-iphoneos32-stop...

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

#107
post #3

Could have been titled: How do Apple devices wreak havoc on home networks. When my kid comes home with his iPhone there is a better than even chance that my home network will go out to lunch. Router reboot time. Never happens with Windows or Android devices coming and going.

This is a known issue on iOS 8.0-8.1. Lookup 'WiFried'.

This is very interesting! I just replied to another commentator mentioning issues apple had with 10.10.1 - 10.10.4 when they updated some aspect of the network stack. both the macOS and iOS issues were apparently caused by the same change. More info here: https://www.macrumors.com/2015/05/26/apple-discoveryd-replac...

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

#108
post #56

Earlier quoted context omitted.

DHCP activity from 4 devices will not slow your network, much less take it down. A DHCP negotiation to get an IP address takes 4 UDP packets, all of them usually below 500 bytes in size. Not even when you have set the lease time to the theoretical minimum of 1s, this traffic will be at all significant in your network.

It will kill my fiber to the home network box that my telco installed, and provides DHCP. It isn't a load issue, it is a "the DHCP server died" issue

"It" won't. Bugs in DHCP / your router/modem/telco's software will.
Post reply on HN