How is NTP clock offset calculated?

For the standard four-timestamp exchange, RFC 5905 defines clock offset as ((T2 - T1) + (T3 - T4)) / 2, where T1 and T4 are client send and receive timestamps and T2 and T3 are server receive and transmit timestamps.

How does ppm drift convert to clock error?

One ppm is one microsecond of frequency error per second. Drift in milliseconds equals ppm multiplied by elapsed seconds multiplied by 0.001.

What sync interval keeps a clock within tolerance?

After subtracting current offset, timing uncertainty, and safety margin from the allowed tolerance, divide the remaining milliseconds by the drift rate in milliseconds per second.

Does this replace monitoring or NTP daemon telemetry?

No. This is a planning calculator. Validate production timing with chrony, ntpd, systemd-timesyncd, PTP tooling, logs, and measurements from your own network path.

Is this NTP drift calculator private?

Yes. Inputs are processed locally in your browser and are not submitted to a backend.

NTP Time Drift Calculator

Calculate clock offset from an NTP exchange, estimate how far a local oscillator can drift between syncs, and check whether a planned poll or holdover interval stays inside your timing tolerance.

All calculations run locally in your browser. Use this as a planning model, then validate production timing with your NTP client telemetry, server health, network path, and monitoring thresholds.

Inputs

Current clock offset Signed offset in milliseconds. Positive means server time is ahead of the local client clock.

Offset source

Oscillator drift rate Frequency error in ppm. 15 ppm is the NTP default dispersion rate used by RFC 5905.

Planned sync interval

Sync interval unit

Missed sync intervals Adds whole poll intervals for holdover planning.

Tolerance budget

Maximum absolute offset The largest total clock error you are willing to allow.

Timing uncertainty allowance Path asymmetry, jitter, daemon precision, or root dispersion allowance in ms.

Safety margin

Warning threshold Optional internal alert threshold below the hard tolerance.

Optional NTP exchange timestamps

Enter T1 through T4 in the same time unit and same reference frame, such as milliseconds relative to a capture start. Used only when offset source is set to timestamps.

T1 client send

T2 server receive

T3 server transmit

T4 client receive

Timestamp unit

Use half-delay as uncertainty

Clock and workload presets

Results

Timing status-

Projected worst-case offset-

Tolerance margin-

Maximum safe interval-

Offset and NTP exchange

Offset used:-

NTP calculated offset:-

NTP round-trip delay:-

Uncertainty allowance used:-

Correction direction:-

Drift and holdover

Drift rate:-

Planned sync interval:-

Drift per interval:-

Holdover interval modeled:-

Holdover drift:-

Remaining drift budget before sync:-

Timeline

Now-

Next planned sync-

Holdover after missed syncs-

Interpretation

Enter values to calculate drift and tolerance.

Metric	Value	Meaning
Results will appear after calculation.

Formulas and assumptions

The optional NTP exchange uses the RFC 5905 equations offset = ((T2 - T1) + (T3 - T4)) / 2 and delay = (T4 - T1) - (T3 - T2). Timestamps must use the same unit and the same relative zero point.

Drift per interval: ppm * seconds * 0.001 milliseconds. One ppm is one microsecond per second.
Projected worst-case offset: |current offset| + uncertainty + safety margin + drift.
Maximum safe interval: (tolerance - |offset| - uncertainty - safety) / (ppm * 0.001) seconds, when the remaining budget is positive.
Holdover: planned sync interval multiplied by one plus the number of missed sync intervals.

The calculator treats drift as a worst-case linear bound. Real NTP clients discipline frequency, reject outliers, and report additional statistics such as root delay, root dispersion, jitter, and stratum. For safety-sensitive or compliance timing, use measured telemetry and a qualified time design.

How to use the result

Start with a measured offset from your NTP client or packet capture.
Use a conservative ppm value if you do not know the device oscillator quality.
Keep the warning threshold below the hard tolerance so monitoring alerts before the clock is out of budget.
For virtual machines, branch links, and asymmetric paths, add explicit uncertainty rather than assuming network delay is symmetric.
For long holdover plans, check hardware temperature behavior and time-source failover, not only the nominal ppm number.

FAQs

What does a positive NTP offset mean?

With the timestamp convention used here, a positive offset means the server clock is ahead of the local client clock, so the client would need to move forward by that amount to align with the server.

Can I use this for PTP or hardware time stamping?

The drift and tolerance budget are still useful, but the four-timestamp formula shown here is the NTP/SNTP exchange model. PTP designs should also account for hardware timestamping, transparent clocks, boundary clocks, and profile-specific limits.

Why is delay divided by two only an uncertainty option?

NTP offset math assumes path delay is sufficiently symmetric. Half the measured round-trip delay is a conservative asymmetry ceiling, but it can overstate uncertainty on a stable LAN and understate risk on asymmetric WAN paths.

What ppm should I use if I do not know the clock quality?

Use a conservative value. RFC 5905 uses 15 ppm as a default dispersion rate, commodity crystals are often modeled around 20 ppm, and unstable virtualized or thermally stressed systems may need a larger bound.

More tools

Infrastructure Time & Date Web Dev Calculators