4 ms·

> There’s a lot to the story that’s obviously made up... Obviously? I think I've had this phone call myself a few times, although in my experience it was never

by geocar 1y ago

> There’s a lot to the story that’s obviously made up... Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate. > I think this is nonsense... why would an invalid or incomplete sendmail configuration default to three milliseconds? This is a wonderful question, and perhaps much more interesting than anything else in the page, but first, let's reproduce the timing; My desktop, a 2017 Xeon E7-8880 (144 cores of 2.3ghz; 1tb ram) with a load of 2.26 at this moment: $ time sleep 0.001 real 0m0.004s user 0m0.001s sys 0m0.003s On my i9-10900k (3.7ghz) current load of 3,31: $ time sleep 0.001 real 0m0,002s user 0m0,000s sys 0m0,001s (In case you think I'm measuring exec; time /bin/echo returns 0's on both machine) Now as to why this is? Well in order to understand that, you need to understand how connect() actually works, and how to create a timeout for connect(). Those skilled in the art know you've got a number of choices on how to do it, but they all involve multiple steps because connect() does not take a timeout as an argument. Here's one way (not too different than what sendmail does/did): fcntl(f,F_SETFL,O_NONBLOCK); if(-1==connect(f,...)&&errno==EWOULDBLOCK){ fd_set a;FD_ZERO(&a);FD_SET(f,&a); if(!select(f+1,&a,&a,NULL,{.tv_sec=0,.tv_usec=0})) { close(f);return error; } } If you read this carefully, you only need to ask yourself how much time can pass between the top of connect() and the bottom of select(), and if you think it is zero like tedu does, you might probably have the same surprise: Computers are not abstract machines, but made out of matter and powered by energy and thus subject to the laws of physics, and so everything takes time. For others, the surprise might be that it's still 3msec over twenty years later, and I think that is a much more interesting subject to explore than whether the speed of light exists.

lordnacho 1y ago
I thought the 3ms was more or less what a low-granularity clock would give you. So, not the clock that gives you nanos, but the big standard one that is useful if you just somewhat care that some timer has run out. Perhaps you use it to count frames (120fps ~ 8.3ms) or check whether some calendar event has happened. A 333 Hz clock seems like something you might have on computers going back to those days, even if not for the CPU.
MadnessASAP 1y ago
> 144 cores of 2.3ghz; 1tb ram I can't help but feel that's somewhat excessive for a desktop. Have you considered closing a few browser tabs?
- geocar 1y ago
 > I can't help but feel that's somewhat excessive for a desktop. I got it on ebay for €2k. You can't not expect me to use it as a desktop. > Have you considered closing a few browser tabs? No? I mean actually no: I made a brotab+wofi script that allows me to search tabs, and I find it a lot more convenient than bookmarks. Here's the relevant bits: brotab_filter='{ split($1,A,"."); t=$2; gsub(/&/, "\\&",t); gsub(/</, "\\<",t); gsub(/>/, "\\>",t); print ""A[1]"."A[2]"."A[3]" Firefox "t"" }'; ( # more stuff is in here brotab list | awk -F" " "$brotab_filter" ) | \ wofi -m --insensitive --show dmenu --prompt='Focus a window' | sed -e 's/<[^>]*>//g' | { read -r id name || exit 1 case "$id" in exec) exec "$name" ;; [0-9]*) swaymsg "[con_id=$id]" focus ;; [a-z]\.*) brotab activate "$id"; sleep 0.2; swaymsg "[title=\"${name#Firefox }\"]" focus ;; esac } Works fine on 19,294 tabs at the moment...
 - lazide 1y ago
 I think I love you.
 - hhh 1y ago
 Jesus christ
 - pseudalopex 1y ago
 > brotab https://github.com/balta2ar/brotab https://github.com/balta2ar/brotab Control your browser's tabs from the command line It has Firefox and Chrome extensions. Thank you for this.
chimeracoder 1y ago
> Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate. Yeah, the original retelling even states up-front: > The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining. It's pretty common to alter minor details of stories in order to make them easier to follow, not to mention that the entire account is also written several years after it happened, when details are presumably less likely to be completely accurate. Obviously the dialogue is reconstructive for narrative ease; no reader would look at that and assume it's intended to be a verbatim transcript. Unless the author here can cite specific things that make it truly impossible for anything of that shape to have occurred, I'm not seeing anything that justifies the conclusion "there's a lot to the story that's obviously made up".
throw310822 1y 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?
- ndiddy 1y ago
  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 https://www.ibiblio.org/harris/500milemail-faq.html
  - throw310822 1y ago
    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.
    - lilyball 1y ago
      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."
    - throwaway31131 1y ago

by geocar 1y ago

lordnacho 1y ago

I thought the 3ms was more or less what a low-granularity clock would give you. So, not the clock that gives you nanos, but the big standard one that is useful if you just somewhat care that some timer has run out. Perhaps you use it to count frames (120fps ~ 8.3ms) or check whether some calendar event has happened. A 333 Hz clock seems like something you might have on computers going back to those days, even if not for the CPU.

MadnessASAP 1y ago

> 144 cores of 2.3ghz; 1tb ram I can't help but feel that's somewhat excessive for a desktop. Have you considered closing a few browser tabs?

geocar 1y ago
> I can't help but feel that's somewhat excessive for a desktop. I got it on ebay for €2k. You can't not expect me to use it as a desktop. > Have you considered closing a few browser tabs? No? I mean actually no: I made a brotab+wofi script that allows me to search tabs, and I find it a lot more convenient than bookmarks. Here's the relevant bits: brotab_filter='{ split($1,A,"."); t=$2; gsub(/&/, "\\&",t); gsub(/</, "\\<",t); gsub(/>/, "\\>",t); print ""A[1]"."A[2]"."A[3]" Firefox "t"" }'; ( # more stuff is in here brotab list | awk -F" " "$brotab_filter" ) | \ wofi -m --insensitive --show dmenu --prompt='Focus a window' | sed -e 's/<[^>]*>//g' | { read -r id name || exit 1 case "$id" in exec) exec "$name" ;; [0-9]*) swaymsg "[con_id=$id]" focus ;; [a-z]\.*) brotab activate "$id"; sleep 0.2; swaymsg "[title=\"${name#Firefox }\"]" focus ;; esac } Works fine on 19,294 tabs at the moment...
- lazide 1y ago
 I think I love you.
- hhh 1y ago
 Jesus christ
- pseudalopex 1y ago
 > brotab https://github.com/balta2ar/brotab https://github.com/balta2ar/brotab Control your browser's tabs from the command line It has Firefox and Chrome extensions. Thank you for this.

chimeracoder 1y ago

> Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate. Yeah, the original retelling even states up-front: > The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining. It's pretty common to alter minor details of stories in order to make them easier to follow, not to mention that the entire account is also written several years after it happened, when details are presumably less likely to be completely accurate. Obviously the dialogue is reconstructive for narrative ease; no reader would look at that and assume it's intended to be a verbatim transcript. Unless the author here can cite specific things that make it truly impossible for anything of that shape to have occurred, I'm not seeing anything that justifies the conclusion "there's a lot to the story that's obviously made up".

throw310822 1y 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?

ndiddy 1y ago
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 https://www.ibiblio.org/harris/500milemail-faq.html
- throw310822 1y ago
  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.
  - lilyball 1y ago
    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."
  - throwaway31131 1y ago