General Interview: How do you choose NTP, PTP, and monotonic clocks?

Prompt and scope

Several servers must record comparable event times while some services also measure deadlines and latency. Explain what NTP, PTP, and a process-local monotonic clock solve, then propose deployment, loss-of-sync behavior, and verification. Assume variable network delay, node restarts, and that time synchronization cannot be treated as causal consistency.

What the interviewer is testing

The key signal is separating comparable wall-clock time, local elapsed time, and event causality. A strong answer asks for the precision budget and network boundary first, then places NTP in general or wide-area synchronization, PTP in a controlled LAN with hardware timestamping, and a monotonic clock in timeout measurement. It does not claim that PTP is automatically more accurate everywhere.

Clarifications before answering

1. What is the maximum tolerated offset? Millisecond audit timestamps often fit NTP; microsecond control is where PTP and hardware timestamping deserve evaluation.
2. Is the network controlled, do switches support IEEE 1588, and are boundary or transparent clocks available? Without them, PTP assumptions may not hold.
3. Is time used for ordering, deadlines, signatures, or compliance evidence? Deadlines use monotonic time; cross-node ordering still needs sequence numbers, versions, or logical clocks.
4. What happens when upstream time disappears: stop writes, degrade, or continue? The answer determines holdover, alert thresholds, and data labels.

Recommended design and derivation

Build a hierarchy: a small set of GPS, atomic-clock, or trusted upstream sources feeds regional NTP servers, and ordinary hosts discipline their wall clocks with NTP. NTP exchanges must account for round-trip delay and path asymmetry, so monitor offset, frequency error, round-trip delay, stratum, and age of the last synchronization rather than only a running service.

PTP propagates a grandmaster clock through switches and can use hardware timestamps to reduce OS scheduling and NIC queueing error. In a controlled LAN with boundary or transparent clocks and hardware-capable endpoints, it can satisfy a tighter error budget than NTP. Across the public Internet or changing cloud paths, verify the actual device and network support before promising that precision.

wall_now = CLOCK_REALTIME      # calendar, logs, cross-node timestamps
elapsed = CLOCK_MONOTONIC      # deadlines, retries, latency measurement
deadline = monotonic_start + timeout

A monotonic clock does not move backward when NTP disciplines wall time, so it is appropriate for elapsed-time calculations. Linux documents distinct semantics for CLOCK_REALTIME and CLOCK_MONOTONIC. Even a well-synchronized wall clock is unsafe for a 30-second timeout because correction can step or slew it.

Alternatives and trade-offs

NTP is simple to deploy, works across routed networks, and has mature operational tooling; its error depends on path and host timestamping. PTP can provide lower offset and jitter in a controlled domain; it depends on NICs, switches, drivers, and clock sources, so the failure domain and configuration are larger. For event ordering, logical clocks or database sequences are often more direct than pursuing tighter physical time. For one-host duration, monotonic time is the right tool for both.

Failure modes, boundaries, and counterexamples

• Treating “NTP synchronized” as proof that business timestamps are accurate while ignoring offset, stratum, and source changes.
• Using CLOCK_REALTIME for deadlines; manual changes or clock correction can make a timeout early or late.
• Promising microsecond PTP accuracy on a cloud host without hardware timestamping; network capability is a precondition.
• Inferring cross-node causality from wall timestamps. Network delay can produce ties or reversed observations; use sequence, version, or logical-clock data.
• Continuing to issue apparently precise signatures or audit records after loss of sync; record time source, sync age, and uncertainty, then label or reject high-risk operations beyond a threshold.

Tests and verification checklist

Verify three layers: test realtime and monotonic semantics on each node; collect NTP/PTP offset, jitter, frequency error, and synchronization age; then inject delay, packet loss, upstream changes, and restarts. State acceptance as “under the specified network and hardware, 99.9% of windows stay below X offset,” and test holdover and recovery separately. A single date comparison is not validation.

Follow-up questions

How should cross-node events be ordered?

Use physical time for display and audit fields, but give causality to monotonic versions, message sequence numbers, database commit order, or logical clocks. If a human-facing timeline is required, expose the uncertainty interval and apply a stable tie-breaker inside overlapping intervals.

Can PTP completely replace NTP?

There is no universal replacement. PTP fits a controlled domain with an explicit precision budget; NTP still covers management networks, wide-area links, and hosts without PTP hardware. A common design uses PTP for a critical domain and offers NTP from services inside that domain to other hosts.

Should a service stop when its time source disappears?

Grade the business risk. Ordinary caches or metrics may continue within bounded holdover; signatures, certificates, or financial matching should reject or escalate when uncertainty exceeds a threshold. Every downgrade needs an alert, a data label, and a calibration record after recovery.