Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cafbit.com

Post reply on HN
Print view View original

91–100 of 114 posts

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

#91

Post by _jal »

johncolanduoni wrote: post #82
dspillett wrote: post #70

Earlier quoted context omitted.

> the DHCP server configuration under Windows Though for the opening to the current discussion that is a moot point - this is not relevant to either OS on the desktop .

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.

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

#92

Post by tbrock »

bobsam wrote: post #71
epistasis wrote: post #11

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

No, but it is still quite fast. On chromeOS network bring up is extremely fast. We are talking 1-3 seconds from cold boot to your emails have been synchronized. My Ubuntu is almost as fast, if we subtract the 4 seconds the ugly bios screen adds. No idea about Android, but did you read the end of the article?

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.

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

#93

Post by Piccollo »

mdekkers wrote: post #88
wtfwtfw wrote: post #28

Earlier quoted context omitted.

> bonus coffee over my screen Why did you pour coffee on your screen? That's really quite strange behaviour.

HN isn't in the mood for levity today....

maybe he was laughing too hard and spit out the coffee that was in the person's mouth

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

#94

Post by finnn »

bobsam wrote: post #71
epistasis wrote: post #11

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

No, but it is still quite fast. On chromeOS network bring up is extremely fast. We are talking 1-3 seconds from cold boot to your emails have been synchronized. My Ubuntu is almost as fast, if we subtract the 4 seconds the ugly bios screen adds. No idea about Android, but did you read the end of the article?

Are you saying that 1-3 seconds includes boot time? Like, time form pressing the power button to email syncing?

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

#95

Post by TD-Linux »

mjw1007 wrote: post #73
rkangel wrote: post #51

Earlier quoted context omitted.

Except that this isn't ignoring red lights, it's taking a government approved shortcut that no-one else has done the research to know about (to extend your metaphor). This approach is standards approved: http://www.ietf.org/rfc/rfc4436.txt

Still PROPOSED STANDARD, eleven years on. Though that says as much about the IETF as that particular RFC.

That's just IETF terminology. Number assignment is one of the last things to happen - so if it has a number, it's done.

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

#96

Post by phh »

epistasis wrote: post #11

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 IP in the first place. If it doesn't do so, and asks for the correct IP address, you save 1.5 RTT. This is because at the time of that article, dhcpcd had one lease file per interface.

In my opinion, between RFC4436, and per-ssid interface, having a per-ssid lease makes a MUCH bigger user-facing change than RFC4436. RFC4436 worst 1-percent gain is 1s, per-ssid lease worst 1-percent is gain 10s.

I suggested a fix to dhcpcd's author: have one lease file per { interface + ssid }. This has been merged in dhcpcd in February 2015 (sorry, it looks like mailing-list archives is down). So the bad feeling of > 10s connection time should be gone when using dhcpcd.

I've also suggested him to implement rfc4436, but got no answer at the time. Considering the friendly answer I had for my previous patch, I guess it just got lost. As far as I can tell, as of today, mainline dhcpcd still doesn't implement it.

ChromeOS uses a patched dhcpcd, which includes RFC4436: https://chromium-review.googlesource.com/c/22643/ https://chromium-review.googlesource.com/c/23906/

isc-dhcp-client, aka dhclient, doesn't seem to include either the ssid-based lease, or the RFC4436.

Android used to use dhcpcd until Android 6, but a very old version. I published an updated version of dhcpcd for rooted Android: https://forum.xda-developers.com/android/software/wifi-dhcp-...

I pushed to Android's gerrit the changes that were merged to dhcpcd (it had to be rewritten, because Android's dhcpcd is really old).

The result of this, is that for Android 6, Google decided to rewrite their own DHCP implementation (mostly because the integration with dhcpcd made a state machine more complex than rewriting a DHCP client). This led to a java dhcp client which doesn't save leases, had flaws which could make an android device reboot, and which doesn't support RFC4436. At least, there is no longer any authoritative problem, since the device will always send a DISCOVER. As far as I know, this still is the current status of Android.

Android Things, which is basically Android... Well, they are using yet another google-written dhcp client. ( https://android.googlesource.com/platform/system/connectivit... ) This supports leases (I couldn't tell based on the sources whether it was interface or ssid-based), but no RFC4436.

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

#97

Post by bobsam »

finnn wrote: post #94
bobsam wrote: post #71

Earlier quoted context omitted.

No, but it is still quite fast. On chromeOS network bring up is extremely fast. We are talking 1-3 seconds from cold boot to your emails have been synchronized. My Ubuntu is almost as fast, if we subtract the 4 seconds the ugly bios screen adds. No idea about Android, but did you read the end of the article?

Are you saying that 1-3 seconds includes boot time? Like, time form pressing the power button to email syncing?

Edit: yes, but it depends very much on hardware. My old arm chromebook was very fast to boot but the Intel ones seem to boot slower:

https://youtu.be/rsTyiMTYq9M

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

#98

Post by epistasis »

phh wrote: post #96
epistasis wrote: post #11

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…

Fantastic, thanks for such a detailed response! My meager web searching skills did not turn up any of this.

And of course, thanks for all this work, it's quite impressive.

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

#99

Post by jlarocco »

Nition wrote: post #19
taurath wrote: post #14

Earlier quoted context omitted.

An instruction like that is why I don't use Linux as a desktop!

I'm a bit disappointed that you're downvoted to grey right now because editing obscure config files and entering esoteric terminal commands is exactly why Linux is so difficult for the average user, and it's never going to improve if those who're already comfortable with it ignore the problem.

OP is downvoted because a misconfigured DHCP server has nothing to do with running Linux. What if the DHCP server was running Windows?

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

#100

Post by bobsam »

tbrock wrote: post #92
bobsam wrote: post #71

Earlier quoted context omitted.

No, but it is still quite fast. On chromeOS network bring up is extremely fast. We are talking 1-3 seconds from cold boot to your emails have been synchronized. My Ubuntu is almost as fast, if we subtract the 4 seconds the ugly bios screen adds. No idea about Android, but did you read the end of the article?

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

Post reply on HN