Thursday, 30 July 2015

Linux NTPD - Network Time Protocol (NTP) daemon

Linux NTPD  - Network Time Protocol (NTP) daemon

       ntpd [ -46aAbdDgLnNqx ] [ -c conffile ] [ -f driftfile ] [ -i jaildir ] [ -k keyfile ] [ -l logfile ] [ -p pidfile ] [ -P priority ] [ -r broad-
       castdelay ] [ -s statsdir ] [ -t key ] [ -u user[:group] ] [ -v variable ] [ -V variable ]


       The ntpd program is an operating system daemon which sets and maintains the system time of  day  in  synchronism  with  Internet  standard  time  servers. It is a complete implementation of the Network Time Protocol (NTP) version 4, but also retains compatibility with version 3, as defined
       by RFC-1305, and version 1 and 2, as defined by RFC-1059 and RFC-1119, respectively. ntpd does most computations in 64-bit floating point arith- metic  and  does  relatively clumsy 64-bit fixed point operations only when necessary to preserve the ultimate precision, about 232 picoseconds.
       While the ultimate precision is not achievable with ordinary workstations and networks of today, it may be required with  future  gigahertz  CPU  clocks and gigabit LANs.


       The ntpd program operates by exchanging messages with one or more configured servers at designated poll intervals. When started, whether for the first or subsequent times, the program requires several exchanges from the majority of these servers so the  signal  processing  and  mitigation  algorithms  can accumulate and groom the data and set the clock. In order to protect the network from bursts, the initial poll interval for each server is delayed an interval randomized over a few seconds. At the default initial poll interval of 64s, several minutes can elapse before  the
       clock  is set. The initial delay to set the clock can be reduced using the iburst keyword with the server configuration command, as described on the Configuration Options page.

       Most operating systems and hardware of today incorporate a time-of-year (TOY) chip to maintain the time during periods when the  power  is  off. When  the  machine  is booted, the chip is used to initialize the operating system time. After the machine has synchronized to a NTP server, the
       operating system corrects the chip from time to time. In case there is no TOY chip or for some reason its time  is  more  than  1000s  from  the  server  time,  ntpd  assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by
       hand. This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the  clock  will  be  set  to  the server  time  regardless  of  the  chip  time. However, and to protect against broken hardware, such as when the CMOS battery fails or the clock  counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway.

   Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous  and  without  discontinuities.  Under  conditions  of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is
       equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets  exceeding  128  ms,  unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset,       steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to  a  vanishingly  low incidence.

       As  the  result  of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path  congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion 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, 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 2,000 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.

       In spite of the above precautions, sometimes when large frequency errors are present the resulting time offsets stray outside the  128-ms  range  and  an  eventual step or slew time correction is required. If following such a correction the frequency error is so large that the first sample
       is outside the acceptable range, ntpd 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 ( comes to mind), there may be  occasional step/slew corrections and subsequent frequency corrections. It helps in these cases to use the burst  keyword  when  configuring  the  server.

No comments:

Post a Comment