SYSTEM Cited by 1 source
Meta Precision Time Protocol (PTP)¶
Meta's Engineering blog post "Precision Time Protocol at Meta" (2022-11-21) is summarized in the High Scalability Dec-2022 roundup.
Headline claim¶
Meta ran a direct experiment comparing their state-of-the-art NTP deployment against an early PTP implementation and measured ~100× better clock accuracy with PTP. Per Meta's post:
"One could argue that we don't really need PTP for that. NTP will do just fine. Well, we thought that too. But experiments we ran comparing our state-of-the-art NTP implementation and an early version of PTP showed a roughly 100x performance difference."
Why clock accuracy pays for itself¶
From HN commenter klodolph, quoted in the roundup — this is
the clearest public explanation of how clock accuracy converts
into dollars saved at hyperscale:
- Snapshot reads of a distributed database avoid acquiring a lock by using a monotonic commit timestamp.
- When a machine writes, it must add a delay equal to the worst-case clock error, to ensure the snapshot is consistent.
- More accurate timestamps → less delay per write → each server can handle more load → fewer servers needed → millions of dollars saved → those savings pay for the teams that build the PTP infrastructure.
This is the same cost-model that Google's systems/truetime + systems/spanner validated at a different datacenter scale. Meta's disclosure is the strongest public confirmation that the commit-wait-equals-clock-uncertainty tax is worth engineering against aggressively.
Design implications for this wiki¶
- Any system with a monotonic-clock-based snapshot model (Spanner, CockroachDB, FoundationDB, YugabyteDB, Oracle RAC with commit SCN, etc.) benefits from PTP-grade time sync.
- NTP is adequate for distributed-log ordering that tolerates seconds of skew; it's not adequate for commit-wait-based distributed transactions at scale.