This page describes what to expect when the NTP daemon ntpd is started for the first time. The discussion presumes the programs in this distribution have been compiled and installed as described in the Building and Installing the Distribution page.
When the daemon is started, whether for the first or subsequent times, a number of roundtrip samples are required to accumulate reliable measurements of network path delay and clock offset relative to the server. Normally, this takes about four minutes, after which the local clock is synchronized to the server. The daemon behavior at startup depends on whether a drift file ntp.drift exists. This file contains the latest estimate of local clock frequency error. When the daemon is started for the first time, it is created after about one hour of operation and updated once each hour after that. When the daemon is started and the file does not exist, the daemon enters a special mode designed to quickly adapt to the particular system clock oscillator time and frequency error. This takes approximately 15 minutes, after which the time and frequency are set to nominal values and the daemon enters normal mode, where the time and frequency are continuously tracked relative to the server.
As a practical matter, once the local clock has been set, it very rarely strays more than 128 ms relative to the server, even under extreme cases of network path congestion and jitter. Sometimes, in particular when the daemon is first started, the relative clock offset exceeds 128 ms. In such cases the normal behavior of the daemon is to set the clock directly, rather than rely on gradual corrections. This may cause the clock to be set backwards, if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line that starts the daemon, the clock will never be stepped and only slew corrections will be used.
The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.
There may be an occasional outlyer, where an individual measurement exceeds 128 ms. When the frequency of occurrence of these outlyers is low, the measurement is discarded and operation continues with the next one. However, if the outlyers persist for an interval longer than about 15 minutes, the next value is believed and the clock stepped or slewed as determined by the -x option. The usual reason for this behavior is when a leap second has occurred, but the reference clock receiver has not synchronized to it. When leap second support is implemented in the kernel, the kernel implements it as directed by the NTP daemon. If this happens and the reference clock source resynchronizes correctly within 15 minutes, the transient misbehavior of the source is transparent.
It has been observed that, as the result of extreme network congestion, the roundtrip delays can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus the error budget terms, can become very large. When the synchronization distance exceeds one second, the offset measurement is discarded. If this condition persists for several poll intervals, the server may be declared unreachable. Sometimes the large jitter results in large frequency errors which result in straying outside the acceptable offset range and an eventual step or slew time correction. If following such a correction the frequency error is so large that the first sample is outside the acceptable range, the daemon enters the same state as when the ntp.drift file is not present. The intent of this behavior is to quickly correct the frequency and restore operation to the normal tracking mode. In the most extreme cases (time.ien.it comes to mind), there may be occasional step/slew corrections and subsequent frequency corrections. It helps in these cases to use burst mode when configuring the server.