Transparency

Measurements and accuracy

How we measure this server's clock, where those measurements stop being meaningful, how it compares with upstream sources, and our leap second policy. Every number comes from the server's own records.

What we measure

every number comes from this server, nothing is estimated

Claiming that a time server is accurate is easy; showing it is not. This page publishes how we measure our own clock, where those measurements stop being meaningful, and what they say. Every value below is produced from the server's own records and is public through the status.json and gnss.json endpoints.

—

PPS pulse stability

standard deviation of the one-second pulses

—

system clock ↔ pulse

chrony's RMS offset

—

published error bound

root dispersion: the uncertainty we advertise to clients

—

frequency uncertainty

how well we know the clock's rate

Method

you can run the same checks yourself

Measurement	How it is done	What it tells you
Pulse stability	The network card's hardware clock timestamps every pulse from the GPS receiver. We measure how far the interval between consecutive stamps deviates from exactly one second.	How cleanly the receiver, the cable and the timestamping chain work. Noise or a loose contact shows up here immediately.
System clock ↔ pulse	chrony locks the system clock to the pulse and records the remaining error every second.	How tightly the server's own clock follows the GPS second.
Independent cross-check	National time laboratories in six countries are queried continuously without being allowed to steer the clock, and the differences are logged.	A systematic error in the GPS chain would be visible: every independent source would drift the same way.
Fix continuity	Satellite count, signal strength and pulse count are recorded once a minute.	How much of the time the service actually runs on GPS. The 24-hour chart on the home page is drawn from this log.

The honest limit of these measurements: we are measuring our own clock against our own reference. That shows how tightly the loop closes, not the absolute accuracy. The terms that bound absolute accuracy — cable delay, the receiver's own error — are listed separately in the accuracy budget. For independent verification, see the comparison table below.

Comparison with upstream sources

they do not steer our clock; they are only measured

Every server below is stratum 1 and operated by a national metrology institute. Because our clock comes from GPS, these sources are queried purely as a control. The values show their time relative to ours.

Source	Institution	Difference	Round trip	Jitter
Loading measurements…

Measurements refresh every five minutes.

The difference is not all error on their side. An NTP measurement assumes the packet takes equally long in each direction. When the path is asymmetric, half of that difference lands directly in the measurement. A few milliseconds of apparent offset on a source with a long round trip is therefore normal and says nothing bad about that institution's clock.

Closer is not always better

This was the most surprising result of our measurements. From our network, the round trip to the national time source in Ankara is 22 milliseconds; to the laboratory in Germany it is 61 milliseconds. Yet the nearby source reads about 5 milliseconds away from our GPS clock, while the distant one stays below 0.2 milliseconds.

The cause is not distance but path symmetry. If packets take one route out and a different route back, NTP cannot see it and writes half the difference into the clock as error. A distant but symmetric path beats a near but asymmetric one. This is also why a GPS-referenced server matters: its time does not come over the network, so network asymmetry cannot distort it.

The same logic applies to you: there is a network between us as well. A server whose own clock is accurate to nanoseconds does not mean you will receive time to better than a millisecond. Clients in the same datacentre see microseconds; for distant clients, their own network path decides.

What happens if the satellites go away

measured behaviour, not a promise

We have a single antenna. It is fair to ask what happens if it fails, the cable breaks or the signal is jammed. We tested it: we cut the satellite data and recorded what the server did.

Stage	What happens	Measured
First minutes of the outage	The server runs on its own clock (holdover), using the frequency it learned while locked to GPS. In a measured 24-minute test the total drift was 1.2 µs.	3 µs per hour · about 14 days to reach 1 ms
At ten minutes	A watchdog service steps in: the satellite source is disabled and time starts coming from national laboratories in seven countries.	switch completes within seconds · the server becomes stratum 2
When satellites return	As soon as pulses flow again the watchdog restores the satellite source.	back to stratum 1 within a minute

The switch is not hidden: the current stratum and time source are stated live in status.json and gnss.json, and the status line on the home page changes immediately. We have no atomic holdover oscillator; during a long outage the accuracy is set by the laboratories on the network.

Leap second policy

when a day lasts 86,401 seconds

The Earth does not rotate at a constant rate. When the gap between its rotation and atomic time grows too large, a leap second is inserted into UTC. Servers handle this in three different ways, and the choice directly affects clients.

Approach	What it does	Our choice
Standard announcement	A flag is sent during the preceding day; when the second is inserted, the clock reads 23:59:60.	This is what we do. It is the behaviour the NTP standard prescribes, and it lets clients apply their own policy.
Smearing	The extra second is spread over 12–24 hours by slowing the clock slightly; 23:59:60 never appears.	We do not smear. A client mixing smearing and non-smearing servers sees inconsistent time for hours. As a pool server, standard behaviour is the correct choice.
Ignoring it	The flag is ignored, the clock ends up one second out and is corrected afterwards.	We do not do this. It produces a step.

The leap second schedule is loaded from leap-seconds.list and compared with what the satellites report. GPS time itself has no leap seconds: its offset from UTC (currently 18 seconds) is broadcast in the navigation message and applied by the receiver. One practical note: your clients should not use smearing and non-smearing servers at the same time.

Measure it yourself

you do not have to take our word for it

The commands below run without touching your system clock and independently verify the values this server claims.

See the server's stratum and error bound

chronyc -N ntpdata ntp.alastyr.com

Measure the offset from your clock read-only

chronyd -Q -t 5 'server ntp.alastyr.com iburst'

Test NTS authentication

chronyd -Q -t 10 'ntsdumpdir /tmp'   'server ntp.alastyr.com iburst nts'

Read the live GPS data

curl -s https://ntp.alastyr.com/api/gnss.json | jq .kilit

For the full method, the table of expected values and common problems, see the verification page.