52
11
I've noticed that on my servers and other machines the clock always drifts so it has to sync up to remain accurate.
How do the NTP server clocks not drift and always remain correct?
52
11
I've noticed that on my servers and other machines the clock always drifts so it has to sync up to remain accurate.
How do the NTP server clocks not drift and always remain correct?
58
NTP servers rely on highly accurate clocks for precision timekeeping. A common time source for central NTP servers is atomic clocks, or GPS receivers (remember that GPS satellites have atomic clocks onboard). These clocks are defined as accurate since they provide a highly exact time reference. There's nothing magical about GPS or atomic clocks that make them tell you exactly what time it is; because of how atomic clocks work, they are simply very good at, having once been told what time it is, keep telling accurate time (since the second is defined in terms of atomic effects). In fact, it's worth noting that GPS time is distinct from the UTC that we are more used to seeing. These atomic clocks in turn are synchronized against International Atomic Time or TAI in order to not only accurately tell the passage of time but also the time.
Once you have an exact time on one system connected to a network like the Internet, it's a matter of protocol engineering enabling transfer of precise times between hosts over an unreliable network. In this regard a stratum 2 (or farther from the actual time source) NTP server is no different from your desktop system syncing against a set of NTP servers.
By the time you have a few accurate times (as obtained from NTP servers or elsewhere) and know the rate of advancement of your local clock (which is easy to determine), you can calculate your local clock's drift rate relative to the "believed accurate" passage of time. Once locked in, this value can then be used to continuously adjust the local clock to make it report values very close to the accurate passage of time, even if the local real-time clock itself is highly inaccurate; as long as your local clock is not highly erratic, this should allow keeping accurate time for some time even if your upstream time source becomes unavailable for any reason. Some NTP client implementations (probably most ntpd
daemon or system service implementations) do this, and others (like ntpd's companion ntpdate
which simply sets the clock once) do not. This is commonly referred to as a drift file because it stores persistently a measure of clock drift, but strictly speaking it doesn't have to be stored as a specific file on disk.
In NTP, stratum 0 is by definition an accurate time source. Stratum 1 is a system that uses a stratum 0 time source as its time source (and is thus slightly less accurate than the stratum 0 time source). Stratum 2 again is slightly less accurate than stratum 1 because it is syncing its time against the stratum 1 source. And so on. In practice, this loss of accuracy is so small that it is completely negligible in all but the most extreme of cases.
1
Respectfully "high stratum" does not mean low stratum number this should be removed from the answer. S2 is higher than S1. For evidence look at the explanation by Prof. Mills (aka Prof NTP) "The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services...Stratum 2 (secondary) servers at the next higher level are synchronized to stratum 1 servers and so on." http://www.eecis.udel.edu/~mills/ntp/html/warp.html
– dfc – 2014-04-25T12:26:55.0372Its better but I do not think that stratum 0 is "by definition an accurate time source." Stratum 0 simply means it is a reference clock of some sort. Just because it is an S0 clock does not mean it is properly functioning. Stratum level is about distance from reference clocks not guaranteed accuracy. – dfc – 2014-04-25T13:35:22.030
@dfc I appreciate the input as it allows me to make the answer even better. That said, I disagree with your statement that S0 does not mean it is accurate. Maybe that is so in a perfectly strict sense, but if the time given by a S0 clock is inaccurate, that clock is useless in practice as a S0 source. Ergo, S0 clocks are accurate. Or put another way, if you have an isolated set of hosts, one of which is connected to a S0 time source and all others sync against that, the time given by the S0 source is the correct time as far as those hosts are concerned. No need to worry about TAI then. – a CVn – 2014-04-25T14:08:29.770
10
In network timekeeping the specification that tells you how a server gets its time source is called a Stratum Level. The lower the level, the better the time keeping of that server.
Stratum level 0 devices are not directly connected to the network. They are the actual timekeeping device itself, and must be connected to a computer to derive the actual time. This computer then becomes a Stratum level 1 NTP server.
A computer connecting to a Stratum level 1 can also become a time server, but it would then be a stratum level 2. As computers connect to time servers, the lower your stratum level, the more accurate your time keeping can be.
Stratum level 0 devices include atomic clocks taking part in TAI (international atomic time) or synchronized to it, and receivers of time signal sent by such clock. Most commonly those are GPS timekeeping receivers with an appropriate interface that includes the GPS PPS signal. The PPS signal, when the GPS has a good lock on several satellites, sends one pulse per second, and the leading edge of that pulse is within nanoseconds of the actual start of that second. Depending on the specification of the GPS receiver, the PPS signal may be more or less accurate. This is because each GPS satellite has an atomic clock. Once the GPS receiver has found its own position and the location of the GPS satellites it's listening to, it can correct for RF propagation and give you time almost as accurate as having an atomic clock right at the GPS receiver.
So Stratum level 1 servers connect to atomic clocks, or GPS receivers, and NTP servers connect to them. Even connecting to a stratum level 2 or 3 server with frequent adjustments will provide your computer with timing accuracy measured in nanoseconds. But if you need better timing, connect to a stratum level one server, or buy an appropriate timekeeping GPS receiver and become a stratum level one source yourself.
4
There are many, many people turning Raspberry PI computers into Stratum 1 NTP servers with the addition of cheap GPS receivers. You can have a complete Stratum level 1 server on your network for under $80: https://www.google.com/search?q=raspberry+pi+ntp+gps+pps
– Adam Davis – 2014-04-23T17:08:27.3102So in theory a smartphone with a GPS receiver (pretty much all of them now) could be a stratum 0/1 device? – Bob – 2014-04-24T04:18:57.730
1If the phone used the pps output of the GPS receiver, yes. Note that CDMA phones have to use precise timing as well, so the CDMA chipset also could be a stratum level 0 source for the phones processor. An oem gps module and raspberry pi would be cheaper though. – Adam Davis – 2014-04-24T13:23:37.153
2A Raspberry Pi doesn't make a great NTP server, though, as it's using a somewhat flaky, low-quality network adapter (the LAN9512 chip). – duskwuff -inactive- – 2014-04-24T20:28:52.463
1@duskwuff Yes, but it's better than many Stratum level 2 servers over the internet, and with properly configured NTP settings on both the server and the client the jitter and offset introduced by the low quality USB based LAN chip can be overcome. For the cost, it's hard to beat, but spend a little more and you can fix this minor issue. – Adam Davis – 2014-04-24T20:31:11.050
1@AdamDavis: The CDMA radio module only needs to do relative timing to find correct offset to correlate the codes and constantly resynchronizes (it may desync for other reasons like the receiver moving). While it needs pretty good time source, it still has error rate on order of 10<sup>-6</sup> to 10<sup>-7</sup> (the clock in GPS receiver do and they are probably comparable) while error rate of atomic clock is on order of 10<sup>-14</sup> and to qualify as stratum 0 they additionally have to be synchronized to TAI (which GPS satellites are). – Jan Hudec – 2014-04-24T20:43:17.683
@diskwuff out of curiosity - isn't the general flakiness of the network layer counteracted for in the NTP protocol? – Thorbjørn Ravn Andersen – 2014-04-25T05:36:48.643
3
All clocks drift to some extent, it depends on the source of the timing signal and how well it is tracked. In a PC, this is the HPET these days, but the PC can lose track of how many ticks have gone by if overloaded.
The NTP servers your machine talks to are likely losing time too, however, they drift their time back to a better source.
Ultimately, the better sources are highly accurate clocks like atomic clocks. You can think of NTP as a network of machines, each one will have a number of sources it relies on for time and skews its own time to what is considered more accurate.
This is governed by a source declaring its stratum. An atomic or GPS clock is stratum 0, and the authority on what the time is. Each layer out from that is the next stratum - stratum 1, and will check a number of stratum 0 sources along with peers at the same level, in order to sanity check the time sources.
You are likely talking to a stratum 2 or 3 time source.
1
What the others wrote is true: a Stratum 1 server gets its time from a Stratum 0 device. I don't know in which time intervals that happens, but I think they are quite accurate there,.
A Stratum n server with n > 1 gets its time via NTP from a Stratum n-1 server. That means it synchronizes to it in regular intervals. Upon starting the NTP service, synchronization happens in quite short intervals, and by time, the intervals start increasing. Eventually, the interval is as large as 1024 s, about 17 minutes.
What hasn't been addressed is the question what happens in-between that time? Well, there is a facility called drift file. It helps NTP to monitor any drift between the local clock and the reference clock. The local clock's frequency is then adjusted according to the detected drift, so that the time is also accurate between server polls.
Other NTP implementation might use other facilities, but one thing is common: the need and the ability to adjust the clock's frequency.
I'd argue however that the drift file is an implementation detail of a particular software implementation, and not related to how the NTP server's hardware clock can be so accurate. – a CVn – 2014-04-25T07:41:38.760
3I, for one, would be specifically interested in a summary about how the NTP protocols allows two computers to sync their time over an unreliable network... – Xavier Nodet – 2014-04-25T04:46:58.053
@XavierNodet While I'm sure you would, that is not what this question is asking about. I'd suggest you ask a question of your own (assuming it has not already been asked; make sure to search first). This question is asking how NTP servers' clocks are able to not drift, while contemporary hardware clocks drift. – a CVn – 2014-04-25T07:38:49.753
@XavierNodet Same here. I like learning about how and why things work the way they do! :) – Jason – 2014-04-25T12:29:32.520