There are several reasons why Internet latency is inflated over direct-route speed-of-light latency. Some reasons may change others may not.
1) speed of light in fibre is 2/3c - unlikely to change soon
2) fibre is laid in the ground on a circuitous route - rarely changes but does happen
3) queueing delay - that's often the main culprit, changeable, but hard (see the buffer bloat debate)
The way I understand this proposal, the idea is to find at which request rate the latency of a storage configuration (eg, 2x Optane) explodes. If your request rate is above that rate, get more RAM. I'm not sure I understand how to figure out how much more RAM? Until the latency goes down I guess?
Also what about diurnal patterns? Can there be a way to dynamically react and save power..
Interesting reference to the morning paper. But don't get how that fits into the story?
Can't you do that with DNS records where there are multiple IPs on a A record?
Basically, we're already doing this for fault tolerance and load balancing within a single CDN. Except that currently we randomize the IPs. To enforce priorities, you'd want the IPs in the A record at least partially ordered by provider.
This is a very hot topic recently. It seems to me that several communities (databases, CDNs, storage, CPU architecture, theory) do a lot of redundant work and don't communicate a lot with each other..
Sounds like a marketing blurb but from just a few days ago:
"Azure is breaking the speed barrier in cloud connectivity. ExpressRoute Direct provides 100G connectivity for customers with extreme bandwidth needs. This is 10x faster than other clouds."
1) speed of light in fibre is 2/3c - unlikely to change soon 2) fibre is laid in the ground on a circuitous route - rarely changes but does happen 3) queueing delay - that's often the main culprit, changeable, but hard (see the buffer bloat debate)