Starlight Tools
LAN NTP client
Inputs: T1=0, T2=4, T3=5, T4=3 ms. Steps: offset=((4−0)+(5−3))/2=3 ms; delay=(3−0)−(5−4)=2 ms. Action: use repeated samples; a stable 3 ms offset may be acceptable for ordinary logging.
NTP Offset, Delay and Clock Drift Calculator
Calculate NTP clock offset and round-trip delay from T1-T4 timestamps, convert oscillator ppm into drift over time, and estimate the maximum sync interval before your clock-error tolerance is exceeded.
Inputs
Use one format for all four values. The calculator converts real timestamps into milliseconds before applying the standard NTP equations.
T1Client sends request
T2Server receives
T3Server transmits reply
T4Client receives
NTP field format accepts seconds:fraction, with fraction as an unsigned 32-bit decimal value.
Convert frequency stability in parts per million into accumulated time error. One ppm is one microsecond per second.
Time drift-
In milliseconds-
Seconds per day-
Seconds per 30-day month-
Enter the current offset, oscillator error, and error budget below to calculate the longest safe interval between successful synchronizations.
Model an outage by setting missed sync intervals. The result includes drift through the planned interval plus every missed poll.
Signed offset in milliseconds. Positive means server time is ahead of the local client clock.
Frequency error in ppm. 15 ppm is the NTP default dispersion rate used by RFC 5905.
Adds whole poll intervals for holdover planning.
Advanced tolerance and holdover controls
The largest total clock error you are willing to allow.
Path asymmetry, jitter, daemon precision, or root dispersion allowance in ms.
Optional internal alert threshold below the hard tolerance.
Clock and workload presets
Status: -Safe interval: -
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-
Projected offsetWarningTolerance
Interpretation
| Metric | Value | Meaning |
|---|---|---|
| Results will appear after calculation. | ||
Advertisement
Advertisement
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.001milliseconds. 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.
Use values from your system
Prefer live telemetry over a generic assumption. Command labels vary by version; preserve the sign convention shown by your client and use absolute ppm for worst-case planning.
chronyc trackingSystem time → current offset; Frequency → drift ppm; Root delay/Root dispersion → uncertainty; polling interval from
chronyc sources -v → sync interval.ntpq -pn / ntpstatoffset → current offset; delay and jitter help choose uncertainty; poll → sync interval. Confirm whether displayed values are milliseconds.
timedatectl timesync-statusOffset → current offset; Poll interval → sync interval; use measured hardware frequency or a conservative ppm assumption.
Windows
The reported offset → current offset. Use
w32tm /stripchartThe reported offset → current offset. Use
w32tm /query /status for source and poll diagnostics; convert seconds to milliseconds when required.Packet capture
NTP originate, receive, transmit, and destination times → T1, T2, T3, and T4. Paste Unix, ISO, NTP seconds:fraction, or relative values above.
NTP originate, receive, transmit, and destination times → T1, T2, T3, and T4. Paste Unix, ISO, NTP seconds:fraction, or relative values above.
Typical NTP and oscillator ranges
| Scenario | Starting values | Rough expectation |
|---|---|---|
| Common NTP polling | 16 s, 64 s, 1024 s | Shorter polling reacts faster; clients normally adapt polling to stability and network conditions. |
| Oscillator assumptions | 1, 15, 20, 50, 100 ppm | 1 ppm = 0.0864 s/day; 20 ppm = 1.728 s/day; 100 ppm = 8.64 s/day without discipline. |
| Stable LAN | Sub-ms to a few ms offset | Low delay and jitter are possible with nearby healthy servers; measure rather than guarantee. |
| Public internet | A few to tens of ms | Routing, congestion, and asymmetry can dominate the oscillator error. |
| Virtual machine | 20–100+ ppm planning bound | Scheduling pauses and host clock behavior can produce steps or non-linear error. |
| RTC / offline holdover | 20–100+ ppm | Temperature and aging matter; validate across the intended outage duration. |
Worked examples
Public internet NTP
Inputs: T1=0, T2=45, T3=47, T4=80 ms. Steps: offset=(45−33)/2=6 ms; delay=80−2=78 ms. Action: treat asymmetry as uncertainty and compare several geographically suitable servers.
Branch appliance outage
Inputs: 8 ms offset, 20 ppm, hourly polls, two missed polls. Steps: holdover=3 h; drift=20×10,800 µs=216 ms. Action: a 250 ms limit is tight once uncertainty is included; restore a source sooner or improve holdover.
Unstable virtual machine
Inputs: 15 ms offset, 100 ppm, 300 s poll. Steps: drift=100×300 µs=30 ms per poll. Action: monitor host pauses and clocksource behavior; ppm alone cannot model clock steps.
Low-latency service
Inputs: 1 ms offset, 1 ppm, 5 ms tolerance, 0.5 ms uncertainty, 1 ms safety. Steps: drift budget=2.5 ms; safe interval=2.5/(1×0.001)=2500 s. Action: alert below the hard limit and validate timestamping in the full request path.
References and assumptions
This is a linear worst-case planning model, not a simulation of a daemon's PLL/FLL, filtering, stepping, or temperature response. Primary references: RFC 5905, NTPsec clock discipline, chrony FAQ, and the NTP offset and delay equations.
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.
How do I calculate NTP offset from four timestamps?
Use ((T2 − T1) + (T3 − T4)) / 2. T1 and T4 are recorded by the client; T2 and T3 are recorded by the server. All timestamps must use the same scale.
What is a good NTP offset?
There is no universal limit. A healthy LAN often achieves sub-millisecond to a few milliseconds, while internet paths may show tens of milliseconds. Define “good” from the application's error budget and observed jitter.
How much time drift is 1 ppm?
One ppm accumulates one microsecond per second, 0.001 milliseconds per second, 0.0864 seconds per day, or about 2.592 seconds per 30-day month.
How do I choose an NTP poll interval?
Start with your daemon's adaptive behavior. For a hard planning bound, subtract offset, uncertainty, and safety margin from tolerance, then divide the remaining milliseconds by ppm × 0.001.
What is root dispersion?
Root dispersion is an NTP estimate of maximum accumulated error relative to the primary reference. It grows with time and contributes to synchronization distance; it can inform a conservative uncertainty allowance.
Why can NTP delay be negative?
A negative computed delay usually signals mixed units, reversed timestamps, clocks or capture fields from incompatible frames, or severe inconsistencies. Recheck field mapping before trusting the offset.
How do virtual machines affect clock drift?
VM scheduling pauses, migration, host synchronization, and clocksource changes can create non-linear drift or steps. Use guest and host telemetry rather than relying only on a nominal oscillator ppm.
Can I use this for chrony or ntpd?
Yes. Map reported offset, frequency, polling, delay, jitter, and dispersion into the corresponding inputs, while remembering each daemon filters samples and disciplines the clock beyond this linear model.