NTP, NTS and GPS: frequently asked questions

Three at least, four ideally. The reason is mathematical: with a single source you cannot tell that the time is wrong. With two that disagree you cannot tell which one is right. With three, if one goes bad the other two still agree and the bad one is discarded.

Configure this server as one of your sources, not as your only source.

The packet format is the same; the difference is what the client does with it. SNTP takes one measurement and sets the clock from it. A real NTP client (chrony, ntpd) measures several sources continuously, filters the measurements, looks for agreement between the sources, and learns and corrects the frequency error of the clock.

From the server side the two look identical. On your servers, use a full NTP client, not SNTP.

We do not smear them. Clients receive the standard leap indicator.

That is why servers that do smear (time.google.com, time.cloudflare.com) are deliberately absent from our upstream list. You should not mix smearing and non-smearing sources either: on a leap second day the two groups drift apart relative to each other, and your client may declare them mutually false and stop synchronising altogether.

It gives you a rough idea, not a precise figure. The measurement is made over HTTP: six requests are sent and the one with the shortest round trip is chosen — a simple analogue of NTP's own filtering logic, and noticeably more accurate than averaging. Server time is read at millisecond resolution.

Even so, TCP/TLS latency, browser timer resolution and asymmetric paths leave a few milliseconds of uncertainty. For a real figure, measure with an NTP client: chronyd -Q 'server ntp.alastyr.com iburst'

It is kept from drifting. The displayed time is your device's clock plus the measured offset, and the offset is re-measured once a minute. The page stays in step with the server however long you leave it open.

But this is only a display — having the page open does not correct your device's system clock. For that you need to configure an NTP client.

Yes. NTS-KE is open on TCP 4460 and the certificate is a publicly verifiable TLS certificate. See the NTS section for usage.

We also connect to most of our backup network sources over NTS — so if the satellites are lost, the chain that takes over is authenticated too.

Being stratum 1 requires a GPS/GNSS receiver and PPS hardware physically attached to the server. We have exactly that: a dual-band antenna, a Quectel LC29H receiver and an Intel i210 network card that timestamps the pulse with its own hardware clock. Because the time does not arrive over the network, network asymmetry cannot distort it.

Even so, stratum is not a quality grade — it is a measure of distance from the reference. A well-connected stratum 2 can serve more accurate time than an overloaded or distant stratum 1. Real quality is measured by root delay, root dispersion and jitter — all three are published live in the status section. If the satellite fix is lost, the server falls back to its upstream sources on its own and continues as a stratum 2.

No. Türkiye has used UTC+03:00 all year round since 2016; clocks are not moved.

If your system's time zone is set to Europe/Istanbul and your tzdata package is current, it behaves correctly. Older tzdata releases may still try to apply daylight saving — if you see a one-hour shift twice a year, that is the first place to look.

Yes — 2a06:ad40:0:1::90. Both NTP (123/udp) and NTS-KE (4460/tcp) work over IPv6, and forward and reverse (PTR) DNS records are consistent.

If you use the hostname, your client will pick whichever is appropriate.

Both are valid, and mixing them is best. This server is registered with the pool.ntp.org project, so writing tr.pool.ntp.org may already land you here — but the pool returns different servers on every query and you cannot know in advance which one you will get.

Naming ntp.alastyr.com directly has two advantages: the address is fixed, and you can connect with NTS authentication, which pool addresses do not support. Our recommendation: configure us directly as one source, and add a couple of pool addresses alongside for diversity.

Yes, that is what it is for. But the service is provided as is, with no legal guarantee.

On critical systems always configure several independent sources — do not depend on this server, or on any single server, alone. If you need legally traceable timestamps, approach TÜBİTAK UME's relevant services directly.

A dual-band (L1 + L5) antenna on the front of the building receives GPS, GLONASS, Galileo and BeiDou signals, which reach the Quectel LC29H receiver in the server over a 20-metre low-loss cable. The receiver produces two separate things:

• NMEA messages: text that says "which second it is now". They arrive over a serial line about 173 ms late and with variable delay, so on their own they are not precise.
• PPS (pulse per second): an electrical pulse that rises exactly at the start of every UTC second. Its edge is sharp to the nanosecond level.

The pulse is wired to a pin on the Intel i210 network card, which timestamps it with its own hardware clock. chrony takes the number of the second from NMEA and its exact moment from the pulse, and locks the system clock to that. The NTP replies sent to you are timestamped in hardware on the same card.

No. GPS time has no leap seconds: it started aligned with UTC on 6 January 1980 and is now 18 seconds ahead of UTC. Galileo system time follows the same scheme. BeiDou time started in 2006, so it is 4 seconds ahead of UTC. GLONASS follows UTC directly (as Moscow time) and applies leap seconds.

The satellites broadcast the difference to UTC in their navigation message; the receiver applies it and aligns the pulse to the UTC second. So this server serves UTC, not GPS time. Upcoming leap seconds are also announced months in advance in these messages; chrony additionally reads the operating system's leap-seconds.list file.

Every satellite carries rubidium, caesium or hydrogen-maser atomic clocks. Ground stations measure them continuously; a satellite clock is not corrected all the time, instead its offset is computed and broadcast in the message, and the receiver applies that correction.

The UTC broadcast by these systems is typically tied to international UTC within a few nanoseconds. The GPS specification's upper limit is 40 nanoseconds. These differences are published monthly by the International Bureau of Weights and Measures (BIPM).

More satellites mean better geometry and more resilience. Typically 25–30 satellites are in the time solution at the same time; the live count is on the home page. If one system has a broadcast fault or maintenance, the others keep carrying the solution.

Even if the view in one direction is blocked for a while, the extra satellites make up for it. The second band (L5) offers a stronger signal that copes better with reflections.

No. The signals are in the 1.2–1.6 GHz range; cloud, fog, night or day make practically no difference. The satellites are in the same orbits at night. The attenuation from heavy rain is a small fraction of a decibel and goes unnoticed.

What can genuinely affect it: snow or ice on the antenna, a new structure blocking its view, nearby radio interference and very strong solar storms. Signal strength and satellite count are live on the home page; the last-24-hours chart shows no difference between night and day.

Three stages take over:

1. When the receiver loses its 3D fix it stops the pulse. This is deliberate: a pulse from a receiver without a fix may be wrong.
2. chrony keeps the clock running on its own at the last frequency it learned. The drift we measured is about 3 microseconds per hour; it takes roughly two weeks to reach 1 millisecond.
3. If no pulse arrives for 10 minutes, a watchdog script switches the clock to national time laboratories and independent stratum-1 servers in six countries and the server becomes stratum 2. When the pulse returns it goes back to stratum 1 on its own.

In a test where we deliberately unplugged and replugged the antenna, the fix returned within 1 second. The holdover measurement is on the measurements page.

NMEA is text arriving over a serial line. It says which second it is, but when it arrives depends on message length, line speed and software load. Here it arrives about 173 ms late and wanders by milliseconds.

PPS is an electrical edge that rises at the start of the second. Timestamped in hardware, its uncertainty drops to nanoseconds. Our pulse is 500 ms wide, which lets chrony tell reliably which edge marks the start of the second. NMEA is used only to give the pulse its second number; it is never a clock source on its own.

Yes. The signal travels slower than light in a cable: the 20-metre LMR-400 cable adds about 78 ns and the antenna's own 3-metre lead about 15 ns. The total, ≈94 ns, is entered in chrony as a fixed correction. Without it the clock would always be that much behind. The other error terms are in the accuracy budget.

Jamming is the more likely scenario and it is safe: the receiver loses its fix, the pulse stops and the process in the previous answer takes over. No wrong time is produced.

Spoofing is harder: a fake signal could lock the receiver to a wrong time. We compare our clock continuously with 11 independent network sources and publish the results; a shift of more than a few milliseconds shows up immediately. A subtle spoof below a millisecond, however, cannot be told apart by network measurement. That is a limit of every single-receiver GNSS time server, and we do not hide it.

No, it is the antenna's height above sea level. The satellite solution first gives height above the ellipsoid that models the Earth (≈132 m here); in İzmir sea level lies about 38 m above that ellipsoid, so the height above sea level comes out at ≈94 m.

The position is published as a long-term average of the live fixes, together with how far the live fixes scatter around it. A stand-alone receiver's absolute accuracy is on the order of 1–2 metres. That is more than enough for timing: a 1-metre position error moves the clock by at most ≈3 nanoseconds.

Our clock follows the pulse to within 1–4 ns (RMS), and the hardware timestamping of the pulse is stable to 2–7 ns. The absolute error of the receiver's pulse against UTC is typically tens of nanoseconds for a dual-band receiver; measuring it directly would need an independent atomic clock.

The accuracy that reaches you is set mostly by the network path: clients in the same datacentre see microseconds, distant ones milliseconds. Our comparison with eleven network sources in six countries is on the measurements page.