
500 miles (2002) - tosh
http://web.mit.edu/jemorris/humor/500-miles
======
nostrademons
I had a similar interview question for Google. I was given a graph of both
average user latency and server load, where average user latency was
_inversely_ correlated with server load, i.e. latency went _up_ when the load
on the server was at its lowest and vice versa, and was then asked to
brainstorm reasons why this could be the case.

The actual answer (I could tell this was drawn from a real experience) was
"China". The valleys in server load corresponded to EST nights, which happens
to correspond to the workday in China. During these time periods, there are
fewer users online, but the vast majority of them are located in Asia, where a
response to them needs to get through the Great Firewall of China and cross a
trans-Pacific cable. Meanwhile, the U.S. west coast is just going to bed and
the U.S. east coast & Europe are sleeping, so all of the low-latency users
drop out of the population sample. It was a nifty application of both
Simpson's Paradox, correlation-is-not-causation, and speed-of-light limits.

Extra points if you can think of how to avoid strange debugging situations
like this in the future.

~~~
nickysielicki
Took me a couple times to read through this to realize that this was asking
about the intermediate trip time between the server and the client rather than
the total round-trip time that it took to process requests, including
processing time.

Very creative question, requires thinking outside the box. I don't think I
would be able to answer it correctly.

~~~
nostrademons
As measured it was actually talking about total round-trip time including
server processing, but it was measured from within the JS on the client, from
start-of-AJAX-request to finish, and so it included both server/client hops in
addition to processing time. That's part of the red herring: since you
_expect_ the bottleneck to be server processing time, you look there first.

A decent partial answer to "How to prevent this?" is to look at additional
metrics - graphing server-only latency would show the expected correlation
with server load and an inverse correlation with total RTT, and would narrow
the search space significantly.

------
iooi
Somewhat related, I just found out that OSX ships with units version 1.0.

The prompt gives "586 units, 56 prefixes" instead of the post's "1311 units,
63 prefixes".

So if you want to try this you can `brew install gnu-units` and run gunits
instead:

"3070 units, 109 prefixes, 109 nonlinear units"

It's pretty annoying that OSX ships with such outdated utilities [1]

[1] [http://meta.ath0.com/2012/02/05/apples-great-gpl-
purge/](http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)

~~~
fisherjeff
In this particular case, you could also just use the equivalent units of
c-msec.

------
ghayes
I love this story and find it refreshing each time I read it. That said, has
anyone ever looked into if it's real or apocryphal? I'd be curious to know.

~~~
lb1lf
I don't know whether the original story was -ahem- embellished a bit or not,
but I do know that after forwarding this to a sysadmin friend of mine running
a host of Sun boxes at the Norwegian University of Science & Technology, he
got somewhat obsessed with replicating this bug - turned out on his hardware
du jour the range was some 1100km (700 miles.)

------
pontifier
I believe the problem here can be used as a proof of proximity in a
blockchain. Imagine 2 specially designed devices that can receive a string,
perform a public key encryption on it, and transmit it with very low
turnaround time.

A bitcoin block hash is found, and 2 participants begin a back and forth
hashing session in which billions of round trips are performed...every minute
or so, a transaction containing the latest result is submitted to the network,
and eventually one is locked in.

An interested party could then verify that the transaction could not have
occurred unless the 2 keys involved were within a certain physical distance
from one another.

Not sure what it could be used for yet, but it's something that feels like it
could be important for some purpose.

~~~
Cursuviam
You could use this to prove that N devices are spread fairly geographically
evenly near the line between two devices you know the location of, if the
transport latency was fairly constant.

If you cross this line over multiple countries, you now have a system where
you can prove that the devices are spread across some number of the different
countries, which probably has some useful properties, like making nation-state
attacks slightly more difficult.

~~~
marcosdumay
I don't think you can prove they have a minimal distance between them, just
maximal. Thus, any data stream may have always came from a single country, you
can only impose an upper limit.

~~~
Cursuviam
Sure, you can prove a minimal distance. Think of this problem as a metal
chain. Each link of the chain enforces a maximal distance on the nodes it
adjoins. The chain is bound on either end to some fixed point.

In an non-constrained case, sure, there's no-minimal link distance. You just
have a pile of chain.

However, if you make the chain taut between the two points, say by decreasing
the number of nodes in the chain or the maximal distance of links, the minimal
distance between nodes then approaches the maximal distance between nodes.
When you have a chain constrained to the straight line between the two points,
the maximal distance between nodes is equal to the minimal distance between
nodes.

------
PLenz
I was today years old when I discovered the units program.

------
ChicagoBoy11
I read this every time it gets posted. Just too good a story.

------
ronilan
I’ve seen this several times before through the years, but somehow missed the
ending.

> “ _I 'm looking for work. If you need a SAGE Level IV with 10 years Perl,
> tool development, training, and architecture experience, please email me at
> trey@sage.org. I'm willing to relocate for the right opportunity._”

I wonder how things turned out for Trey...

~~~
ghayes
From Trey's FAQ on the story, linked below [0]:

    
    
        22. The signature says you're looking for work. Are you still?
        
        Nope, but thanks for asking!
    

[0] [https://www.ibiblio.org/harris/500milemail-
faq.html](https://www.ibiblio.org/harris/500milemail-faq.html)

