Articles
NTP Interview Questions: Clock Skew, chrony Output, and Safe Recovery
Practice NTP interview questions with chrony tracking, source selection, offset and drift diagnosis, clock corrections, and application-safe recovery checks.
A Linux host reports a small NTP offset, yet authentication failures continue. Another host has reachable time servers but no selected source. Neither incident is solved by saying “restart NTP” and hoping the clock looks better.
NTP interview questions test your ability to distinguish clock offset, frequency drift, measurement uncertainty, and application consequences. The difficult decision is often how to recover safely, not how to spell a command. This guide uses original timestamp calculations and synthetic chrony observations; no output below was collected from a production host, and no clock-changing command is executed or recommended without an approved recovery plan.
The diagnostic definitions here use the chrony 4.8 manual and NTPv4 specification, checked in October 2026. Verify the installed implementation and version before applying their details elsewhere.
What is the difference between offset, drift, and uncertainty?
Offset is a difference between clock readings at a point in time. Frequency drift concerns the rate at which that difference changes. Uncertainty describes how confidently the measurement or estimate bounds reality. In an answer, attach a unit and reference clock to each number.
The chronyc tracking reference distinguishes remaining system-clock correction, offset estimates, frequency in parts per million, and frequency skew. “Clock skew” in an interview prompt may mean wall-clock disagreement informally; chrony’s Skew field specifically concerns frequency-estimate error. Clarify the intended meaning.
Use a synthetic oscillator example: an uncompensated 20-ppm rate error accumulates approximately 20 / 1,000,000 × 3,600 = 0.072 seconds in an hour. That is 72 milliseconds. It does not mean the currently corrected host is necessarily 72 milliseconds wrong; active synchronization changes the observed outcome.
A candidate who translates ppm directly into current offset skips a causal step. Ask how long the host has been without reliable correction and what estimate was available before that interval. A large accumulated offset can coexist with a fairly ordinary oscillator rate; a tiny current offset can coexist with uncertain future holdover behavior.
Calculate offset from four timestamps
NTP uses a client send timestamp, server receive timestamp, server send timestamp, and client receive timestamp. RFC 5905, section 8 specifies the offset and round-trip delay calculations. Define the sign convention before doing arithmetic.
For this original fixture, all timestamps are seconds on the respective clocks. The server-minus-client offset estimate is:
T1 client sends: 100.000
T2 server receives: 100.050
T3 server sends: 100.060
T4 client receives: 100.090
offset = ((T2 - T1) + (T3 - T4)) / 2
= (0.050 - 0.030) / 2 = +0.010 seconds
delay = (T4 - T1) - (T3 - T2)
= 0.090 - 0.010 = 0.080 seconds
The estimated server clock is 10 milliseconds ahead, with an 80-millisecond network round trip after excluding server processing. Do not mix that sign convention with a tool field that reports local-clock lead or lag using different wording.
Now challenge the estimate. The calculation cannot independently observe one-way network delays. If the forward path takes 50 milliseconds and the return path takes 30 milliseconds while clocks actually agree, this same arithmetic produces a 10-millisecond apparent offset. That is an original demonstration of how path asymmetry can look like clock error.
One sample therefore does not justify a strong accuracy claim. Compare repeated observations, source agreement, variability, and the measurement path. If the question requires tighter synchronization than the network can support, state the limit instead of hiding it behind more decimal places.
Read chrony output without misinterpreting healthy-looking fields
These are synthetic observations for interpretation, not a complete pasted command report:
| Observation | Meaning to investigate | What it does not establish |
|---|---|---|
| System time: 0.002 seconds slow of NTP time | Remaining system-to-chrony-clock correction | Absolute UTC error is exactly 2 ms |
| Frequency: 20 ppm slow | Estimated uncompensated rate tendency | Current offset equals 20 ms |
| Skew: 0.5 ppm | Error bound on frequency estimate | Wall-clock disagreement equals 0.5 seconds |
| Root delay: 0.020 seconds | Delay contribution toward the reference | A direct local-server RTT measurement only |
| Root dispersion: 0.003 seconds | Accumulated uncertainty contribution | Every request must be within 3 ms |
The definitions and tracking accuracy bound are in the chrony manual. Under its assumption that the reference is correct, the fixture’s bound is 2 ms + 3 ms + 20 ms / 2 = 15 ms. A small remaining correction alone is weaker evidence than that combined picture.
Use this as a reasoning exercise, not a product SLA. If the application requires five-millisecond agreement, a fifteen-millisecond bound does not support declaring success. Identify whether the bottleneck is source quality, network uncertainty, remaining correction, or an inappropriate requirement for the chosen system.
Also check measurement age. A satisfactory estimate from an earlier interval may not establish current health after suspension, migration, network isolation, or a source change. Preserve timestamps alongside values so your conclusion is tied to the incident window.
Can a reachable source still be unusable?
Yes. In chronyc sources -v, Reach is an octal eight-bit history; 377 represents successful responses or samples for the last eight polls. It is not a millisecond measurement or a percentage. Selection state is a separate signal. The source-output documentation describes both.
For a synthetic source row, read ^?, Poll 6, Reach 377. The caret identifies a server; ? means the source is not selectable for reasons that can include insufficient measurements or an unsynchronized source, not just network unreachability. Poll 6 represents a nominal 64-second polling interval.
Ask the candidate to explain why “UDP is reachable” cannot finish the diagnosis. Transport success gets a response to the host; it does not establish a trustworthy, sufficiently measured time source. A source marked x or ~ points toward disagreement or excessive variability rather than simply no packets.
Do not choose a source only because its stratum is numerically lower. Consider the selection result, agreement, freshness, and uncertainty together. Likewise, three hostnames are not necessarily three independent clocks or network paths. Explain what independence would mean in the deployment you are discussing.
Why can stepping the clock be unsafe?
Slewing changes the rate to apply correction gradually; stepping makes a discontinuous adjustment. chrony normally favors gradual correction, and its configuration manual recommends considering startup before time-sensitive programs run for stepping behavior.
makestep 1.0 3 is a configuration example: the threshold is one second and the limit concerns early clock updates after chronyd starts. The 3 is not a three-second wait. Restarting the daemon may therefore have a different effect from merely requesting fresh diagnostics; inspect startup policy before suggesting a restart as a harmless fix.
The bare chronyc makestep command changes the system clock. Discuss it as a consequential action, not a read-only diagnostic. Before an approved step, identify applications that use wall time for scheduled work, lease interpretation, authentication validity, audit records, or cross-host comparisons.
An original application example makes the risk concrete. A program records a request start at wall time 12:00:01. The clock steps backward five seconds. It records completion at 11:59:57. A naive subtraction reports negative duration although the work took one second. Fixing the clock offset does not repair the program’s duration measurement.
Conversely, a forward jump can make an absolute expiry appear immediately past. The correct operational response depends on the application’s contract. Draining work, establishing a maintenance window, or waiting for gradual correction may be safer than forcing an immediate jump; those are decisions to validate with the service owner, not universal instructions.
Which clock should an application use?
Use wall time when the meaning is a calendar instant, and an appropriate monotonic clock for local elapsed durations. Linux CLOCK_MONOTONIC avoids discontinuous wall-clock jumps but is affected by frequency adjustments and excludes suspended time; CLOCK_BOOTTIME includes suspension. See the Linux clock_gettime manual.
An interview answer should add scope. A monotonic reading is not a globally comparable timestamp across machines or reboots. Storing another host’s monotonic value and comparing it locally is not a clock-skew solution. For distributed event order, explain the system’s actual ordering and consistency mechanism rather than pretending synchronized wall clocks prove causality.
For a timeout that must include laptop suspension, ask whether the runtime’s timer abstraction includes sleep. For request latency during continuous operation, define the monotonic start and end on the same host. For “run at 09:00 UTC,” wall-clock semantics remain relevant and clock corrections need a policy.
Keep these requirements distinct in code review. One shared helper named now() can hide calendar time, duration measurement, and event ordering behind the same call. Better naming exposes the contract even before you inspect the implementation.
Build an application-safe recovery answer
Begin with observation. On an authorized Linux host with chrony installed, these commands inspect state rather than changing time:
chronyc tracking
chronyc sources -v
chronyc sourcestats -v
Record the daemon version, selected source, measurement freshness, correction, uncertainty, and frequency estimate. Compare the incident’s timing with VM pause or migration, network changes, and application logs. Use UTC when correlating hosts and preserve the original timezone context.
Then narrow the cause. Is the daemon running? Are replies arriving? Are sources selectable? Is the system still applying a correction? Are applications reading the expected clock? A token-validity failure could involve a wrong issuer, expiration value, or verifier tolerance as well as time; do not silently weaken authentication checks to make symptoms disappear.
Choose recovery only after the impact assessment. If the estimate is trustworthy and gradual correction meets the service’s budget, monitor convergence. If an approved step is necessary, coordinate workload handling and verify the configured behavior. Repeated restarts without evidence can discard context and trigger startup policies unexpectedly.
Define success in advance: sustained selectable sources, fresh observations, correction and uncertainty within the application’s stated budget, and disappearance of the actual user-facing failure. A single healthy command after a restart is only a snapshot. Compare several samples across the relevant polling period and retain the evidence.
For a concise handoff, keep four facts together: the incident window, the last trustworthy measurement, the permitted recovery action, and the next acceptance check. Add the workload owner and rollback or containment decision when a jump is contemplated. This makes the answer reviewable even if another engineer takes over before correction finishes. It also prevents a later observer from confusing “daemon restarted” with “application recovered.”