500 miles (2002)
web.mit.edu
web.mit.edu
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.
I doubt that they would ask the same question now - for one, most Chinese queries are served out of datacenters in Southeast Asia now (at least when I left; if I believe the Project Dragonfly news I hear about on HN they may be served from inside China), so there's no trans-Pacific cable hop. The Chinese population has also gotten a lot more access to broadband & high-bandwidth mobile connections in the decade since this interview.
“China” would have been my first answer to that question.
After spending so much time in a project that deals with massive amounts of HTTP requests from China, I realized that the majority of web developers are making too many assumptions. Several times I have found myself patching pieces of code because the connection was suddenly dropping in the middle of the operation, so I had to add retries and read incomplete streams of bytes to recover at least pieces of the actual data from our Chinese netizens.
In retrospective, I have learned a lot about TCP in the last year with this project.
I think I'll be calling bullshit on this.
Just, you know, so the undies come unbunched before people comment.
https://www.baidu.com/s?wd=19890604&rsv_spt=1&rsv_iqid=0xfd2...
No blocking there and it's a Chinese search engine!
Very creative question, requires thinking outside the box. I don't think I would be able to answer it correctly.
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.
When I first started with Amazon, I was a dev on the team owning the UI component that all warehouse Picking associates used. Had to run on mobile handscanners with IE5.5. The UI was dead simple, pretty darn fast and that speed matters for worker efficiency. Taking 3 seconds between an item scan and the next pick being displayed was unacceptably slow.
One night a few weeks after Christmas, I got an autocut alarm at around 10pm. It said "PickUI page loads 90th percentile > 5 seconds" or something to that effect. I logged in and sure enough, the latency was spiking up and down like crazy for the entire European stack. All our dependencies were rock solid, metrics showed stable performance. Network was fine, no issues. Rendering was normal. But the round trip latency from the users' perspective (sent via Ajax post after a page load) was showing some round trips were taking 15 seconds!
After 30 minutes of scratching my head, I happened to accidentally switch my graph from "P90 latency" to "number of data points". There were very, very few. It turned out that since the Christmas season was just over, all the EU wearhouses were only running day shifts that week. (That doesn't happen very often anymore, I hear). In the entire European region, there was one picking associate working. And she was picking in some area with poor WiFi signal. Around 20% of the time, her page loads were slow because her WiFi sucked. I drew out a rough map of the locations she picked from and the latency- they was some kind of dead zone. But she was the entirety of my metrics for Europe, so that meant my 90th percentile was terrible.
I modified the alarm to have a minimum number of data points threshold and went to bed.
However, minimum(rtt) was ~300 msec for probes in several mainland locations, some <100 km from Hong Kong. Why might that have been?
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]
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.
He could use timeout as a proxy for distance because all the e-mail recipients were within the same university, with a direct-switched network. Once it got on the wire, the only latency was from speed-of-light.
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.
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.
If that picture is of you, you can thus prove that you were in a particular place at a particular time.
> “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...
22. The signature says you're looking for work. Are you still?
Nope, but thanks for asking!