Locality: node, rack, zone, any

When does it matter which machine is near the data, and how do you test it?

Data is closer to some machines than to others. The usual levels are the same node (machine), the same rack, the same zone, or anywhere. The levels exist because the network is a tree with oversubscription at each level: bandwidth gets scarcer as traffic goes up the tree.

Placement expresses locality as a relaxation sequence, not a hard constraint: try the same node; if it is busy, try the same rack; then the same zone; then anywhere. A hard locality requirement would make the scheduler infeasible the moment the right node is busy. The time bound on each relaxation step is exactly delay scheduling.

The modern test: bandwidth per core

What is worth deriving is the modern test for whether locality matters at all. It is not a latency ratio. It is a bandwidth ratio per core.

A task that reads B bytes and computes for C seconds demands B/C bytes per second from the network.

Now change the workload to a shuffle (all-to-all exchange of data between workers). B/C is large, and traffic is all-to-all rather than one-to-many, so the same arithmetic reverses. That is why shuffle data lives on local NVMe disks (very fast solid-state drives attached directly to the machine) even in architectures that separate everything else.

Locality is a bandwidth-per-core question, not a latency question: compare bytes-per-CPU-second with the network card's bandwidth divided by cores.