3 ms·
It's a cute story but one that is utter nonsense. Anyone who is above junior level system or network administration should be able to instantly tell, on point
by KennyBlanken 5y ago
It's a cute story but one that is utter nonsense.
Anyone who is above junior level system or network administration should be able to instantly tell, on point #2 alone. If they don't, they do not understand the basics of TCP.
1)Wave propagation through copper wiring is a bit more than half the speed of light. Strike one.
2)His mail server sends a SYN which is acknowledged by an SYN-ACK back. His mail server does not know instantaneously that the other mail server is accepting the connection; it has to wait for a reply back. A mail server that is '3ms away' even assuming speed of light transmission and no switching/routing/transmission delay would be ~250 miles, not ~500.
3)A mail server does not instantaneously reply to a SYN packet, so there's delay there. Strike three.
4)There are multiple routers involved (at least two) and especially circa 2002 routing and switching probably accounts for a significant amount of delay. Routers and switches tend to be store-and-forward; they receive the entire packet, an interrupt is generated by the NIC, a routing decisions is made, the packet is shoved into the buffer of the outgoing NIC, etc. That doesn't even cover firewalling. 3ms delay through multiple circa-2002 routers, firewalls, and switches is not believable.
5)Transmission delay. Packet take longer than just "distance divited by the speed of light" to arrive somewhere. Given typical LAN/WAN connection speeds of the day, packet transmission delay would be a factor. Ie the time it takes for a complete packet's bits to be transmitted.
6)Jitter. Even the slightest jitter would have wildly affected his testing. Just 2-3ms of jitter (if we follow this guy's calculations) would result in undeliverable mail to almost anywhere, yet he claims mail within the radius was reliably delivered. The campus network (particularly inter-building links), internet uplink, backbones, other network, and other mail server all have jitter that combined would easily exceed 2-3ms.
I also find it extremely difficult to believe that sendmail on SunOS defaults to a 3ms timeout and lacks a sane default when not specified; 3ms isn't remotely sane even today, much less 2002. Anything less than 30 seconds would surprise me. Lot of old software had very long timeout values because of how common slow links and systems were.
This looks like a viral story told by an unemployed sysadmin to get his "I'm looking for a job" message out.
If he truly had the knowledge commensurate with 10+ years as a sysadmin, he knew it was bullshit, and I think he might have been very cleverly looking for places where technical knowledge was lacking and thus he'd either be the smartest guy in the room or have an easy time of things.
- eminence32 5y agoIf you haven't already, read the accompanying FAQ: https://www.ibiblio.org/harris/500milemail-faq.html https://www.ibiblio.org/harris/500milemail-faq.html
- KennyBlanken 5y agoThe only takeaway from that I get from that FAQ is that he's annoyed people think it's fake despite the fact that he admits he made up almost every aspect of the story. It's an entertaining story without changing numbers to bogus ones. So why did he basically lie about everything? Because it never happened and when he concocted the story he wasn't very smart. Notice he doesn't admit that the sole purpose was to spam "I need a job" to the mailing list?
- kazen44 5y ago> Routers and switches tend to be store-and-forward; they receive the entire packet, an interrupt is generated by the NIC, a routing decisions is made, the packet is shoved into the buffer of the outgoing NIC, etc. That doesn't even cover firewalling. 3ms delay through multiple circa-2002 routers, firewalls, and switches is not believable. this acutally hasn been true for high level routers since the late 90's. On an Juniper M and MX series device for instance, a packet is broken up into a "parcel" (the first 256 bytes of an IP packet) and is saved in shared memory. Further packet processing is done by dividing up parcel lookups to the routing table across different linecard processors. (depending on the linecard, this can differ wildly). This setup has been in place since the late 90's, although not on "lower end" hardware. As far as i am aware, cisco has a similair mechanism in their higher end products for atleast a decade or two.