Comment by throw310822
7 months ago
Never got this, honestly.
Well, first light does 500 miles in 3ms, but the connect signal needs to come back, right? So it should be 250 miles, at most? But this is just a detail.
More importantly, because it seems to assume that all other operations besides the signal actually reaching the destination are instantaneous. As you point out yourself, computers are not abstract machines, so the actual response time between the signal being received by the destination (even assuming it's just one straight line with zero electronics in between) and the destination replying is not zero. I imagine there can be a large variation between physical installations and different types of hardware, so much as to make it very hard to detect a clear 500 miles boundary.
Or am I missing something?
The author wrote an FAQ several years after the original story that answers most of your questions. https://www.ibiblio.org/harris/500milemail-faq.html
Yes I think I had read those FAQ at some point, they're terribly handwavy though.
"Should have been 6ms instead of 3 for the ACK to come back? Yes, sorry, it was too boring to add"; "Should it be much more and variable because of the routers in between? Yes sure, I probably pinged them and added up the delays"; "Shouldn't plenty of deliveries have failed for destinations much closer than 500 miles? Yes sure, but that must have been the limit..." Etc.
The "destinations much closer than 500 miles" was explicitly handled in the story, I don't know why that was even in the FAQ except that the asker failed reading comprehension.
> "There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius."
And there's also this nuance from the article text,
"The secret here is the kernel will always round 3ms up to at least one whole tick, 10ms."
Interestingly, not covered in the FAQ.
1 reply →
> Well, first light does 500 miles in 3ms, but the connect signal needs to come back, right? So it should be 250 miles, at most?
I don't think this is terribly important (NB my examples have nothing to do with networking), but in the author's case it was probably the other way; maybe 10msec and a bit more: Copper gets up to ~0.6c but I think this detail makes the story less amusing, and is a distraction from wondering why does select() take so long...
> I imagine there can be a large variation between physical installations and different types of hardware
There is probably not as much as you think, and Sendmail retries, so with whatever variation that exists, only the bounds really matter.
> Or am I missing something?
Modern unixish systems have the same log-scale delay coming out of select() so this has almost nothing to do with the hardware being slower or variability in the network.