To expand on this: if you're designing / building / assembling a computer or cluster, and components are 6" apart, then the minimum latency for communicating between those components is 1 nanosecond.
Given clock speeds of multiple GHz, that means spending an entire clock cycle or more simply communicating between components.
(A Sendmail misconfiguration resulted in a maximum response time of 3 milliseconds, or roughly 500 miles of travel at the speed of light. The observed behaviour was that a uni campus computer could send email only within a 500 mile radius, as noted by the statistics department.)
> Given clock speeds of multiple GHz, that means spending an entire clock cycle or more simply communicating between components.
Yeah that's expected isn't it? That's why we have caches on die. Nobody is out there expecting main memory reads to retire in a clock cycle, let alone IO! I don't think even lower tier cache access retires in a single clock cycles. That's just not how processors work these days.
It's clusters. It's datacentres. It's tools which span the globe. Or extend into space.
The Web by default is now transacted over HTTPS. This means that every session requires a TLS handshake:
- Client hello
- Server hello + key
- Client key exchange.
- Server finished.
- Client finished.
- Data transfer begins.
That's six exchanges, and three round trips. For an antipodal set of hosts, at 300ms per trip, that's nearly 2 seconds just to set up a session. If you're communicating with a Moon base, it's eight seconds.
And if you're using a tool or protocol which presumes cheap or fast round-trips, and uses a lot of round trips, you may find it's unusable.
Some years back a multi-campus site rolled out a remote-console tool that worked across platforms in datacentres --- we had both Linux and Windows hosts.
Working locally with the DC one building over in the campus, or even with a facility elsewhere in the province, performance was laggier than local, but tolerable. The team operating out of Dubai was waiting five minutes to see login screens presented.
Which gets back to my, and Hopper's, initial point:
Space adds time.
If you're doing something, anything, which involves communicating between two or more components frequently, then the further apart those components are, the longer it will take.
(It's also more likely to be affected by other issues --- latency, unreliability, interference, injection, exfiltration, ...)
And that will grow linearly with distance as a multiple of interactions.
There's a lot of code and processing which presumes delays are small and components are near. As those assumptions are violated, performance tends to degrade spectacularly.
Given clock speeds of multiple GHz, that means spending an entire clock cycle or more simply communicating between components.
See also the case of the 500 mile email: https://www.ibiblio.org/harris/500milemail.html
(A Sendmail misconfiguration resulted in a maximum response time of 3 milliseconds, or roughly 500 miles of travel at the speed of light. The observed behaviour was that a uni campus computer could send email only within a 500 mile radius, as noted by the statistics department.)