Nerzen NTP Loading status TR

Measurements and accuracy

Every chart on this page is generated from the server's own measurements and updated once a minute. Raw data: history.json.

System clock offset
—
right now, relative to the selected source
RMS offset
—
long-term average
Frequency correction
—
measured error of the oscillator
Frequency uncertainty
—
bound on drift rate if sources are lost

System clock offset

last 24 hours · instantaneous difference from the selected source

RMS offset

last 24 hours · long-term average of the offset

Frequency correction

last 24 hours · ppm · a flat line means a stable oscillator

Root delay

last 24 hours · round trip to the primary clock

What we measure

  • System clock offset: the instantaneous difference between the server's clock and the "true time" computed from the combination of the selected sources. The closer to zero and the flatter, the better.
  • RMS offset: the long-term root mean square of that same difference; a stability indicator that is not thrown off by momentary spikes.
  • Frequency correction: how fast or slow the server's oscillator runs (in parts per million) and how chrony compensates for it.
  • Root delay and root dispersion: the total round-trip time to the primary clock and the accumulated uncertainty. Clients use these when comparing servers.

Measurement method

The server queries each source every 64–256 seconds. Each query yields four timestamps, from which the round-trip time and the clock difference are calculated. For each source, chrony applies linear regression to the recent measurements, discards sources whose error bounds do not overlap, and adjusts the clock's frequency according to a weighted combination of the rest. The values we publish are chrony's tracking, sources and serverstats reports; no correction or rounding is applied to them.

Why the nearby source gets selected

NTP assumes that a packet takes the same time on the way out as on the way back. In reality the paths can differ; half of the difference shows up directly as clock error and cannot be distinguished by measurement alone. That is why a distant national laboratory with a 60-millisecond round trip can appear to us to be off by a few milliseconds even if its clock is perfect.

For this reason chrony assigns each source an answer to the question "how wrong could it be in the worst case" (half the delay + dispersion) and prefers the one with the tightest bound. This is why, in the source table, a server inside the country appears as the system reference while the distant ones appear as cross-checking: the distant ones do not steer the clock, but they are always there as witnesses that would give the nearby one away if it went wrong.

Reading the table: if a source's offset is within its own error bound, it agrees with our clock. For distant sources, a constant difference of a few milliseconds is the signature of the path, not of the clock.

If sources are lost

If the selected source stops responding, chrony switches to the next best one; this switch is invisible to clients. If all sources are lost at once, the server carries on on its own oscillator with the last measured frequency correction, and the published root dispersion grows over time. Under no circumstances is the clock stepped backwards or forwards.

Leap second policy

The leap second announcement is passed to clients in NTP's standard field; the second is inserted at the end of the day. No smear (spreading the second over several hours) is applied.

Run your own measurement

You don't have to take our word for it. You can configure the server side by side with other sources you trust and see the difference for yourself:

chrony · measurement only, the clock is not changed
chronyd -Q -t 10 'server time.nerzen.com iburst'

# or a per-source comparison on a running chrony:
chronyc sourcestats
chronyc ntpdata time.nerzen.com

The Root delay and Root dispersion fields in the ntpdata output should match the values we publish on this page.