contrib/ntp/html/quick.htm

   1 <HTML><HEAD><TITLE>
   2 Quick Start
   3 </TITLE></HEAD><BODY><H3>
   4 Quick Start
   5 </H3>
   6
   7 <img align=left src=pic/panda.gif>FAX test image for SATNET (1979).
   8
   9 <p>The baby panda was scanned at University College London and used
  10 as a FAX test image for a demonstration of the DARPA Atlantic
  11 SATNET Program and the first transatlantic Internet connection in 1978.
  12 The computing system used for that demonstration was called the <A
  13 HREF="http://www.eecis.udel.edu/~mills/database/papers/fuzz.ps">Fuzzball
  14 </A>. As it happened, this was also the first Internet multimedia
  15 presentation and the first to use NTP in regular operation. The image
  16 was widely copied and used for testing purpose throughout much of the
  17 1980s.
  18 <br clear=left>
  19
  20 <H4>Introduction</H4>
  21
  22 <p>This page describes what to expect when the NTP daemon <tt>ntpd</tt>
  23 is started for the first time. The discussion presumes the programs in
  24 this distribution have been compiled and installed as described in the
  25 <a href=build.htm>Building and Installing the Distribution</a> page.
  26
  27 <p>When the daemon is started, whether for the first or subsequent
  28 times, a number of roundtrip samples are required to accumulate reliable
  29 measurements of network path delay and clock offset relative to the
  30 server. Normally, this takes about four minutes, after which the local
  31 clock is synchronized to the server. The daemon behavior at startup
  32 depends on whether a drift file <tt>ntp.drift</tt> exists. This file
  33 contains the latest estimate of local clock frequency error. When the
  34 daemon is started for the first time, it is created after about one hour
  35 of operation and updated once each hour after that. When the daemon is
  36 started and the file does not exist, the daemon enters a special mode
  37 designed to quickly adapt to the particular system clock oscillator time
  38 and frequency error. This takes approximately 15 minutes, after which
  39 the time and frequency are set to nominal values and the daemon enters
  40 normal mode, where the time and frequency are continuously tracked
  41 relative to the server.
  42
  43 <p>As a practical matter, once the local clock has been set, it very
  44 rarely strays more than 128 ms relative to the server, even under
  45 extreme cases of network path congestion and jitter. Sometimes, in
  46 particular when the daemon is first started, the relative clock offset
  47 exceeds 128 ms. In such cases the normal behavior of the daemon is to
  48 set the clock directly, rather than rely on gradual corrections. This
  49 may cause the clock to be set backwards, if the local clock time is more
  50 than 128 s in the future relative to the server. In some applications,
  51 this behavior may be unacceptable. If the <tt>-x</tt> option is included
  52 on the command line that starts the daemon, the clock will never be
  53 stepped and only slew corrections will be used.
  54
  55 <p>The issues should be carefully explored before deciding to use the
  56 <tt>-x</tt> option. The maximum slew rate possible is limited to 500
  57 parts-per-million (PPM) as a consequence of the correctness principles
  58 on which the NTP protocol and algorithm design are based. As a result,
  59 the local clock can take a long time to converge to an acceptable
  60 offset, about 2000 s for each second the clock is outside the acceptable
  61 range. During this interval the local clock will not be consistent with
  62 any other network clock and the system cannot be used for distributed
  63 applications that require correctly synchronized network time.
  64
  65 <p>There may be an occasional outlyer, where an individual measurement
  66 exceeds 128 ms. When the frequency of occurrence of these outlyers is
  67 low, the measurement is discarded and operation continues with the next
  68 one. However, if the outlyers persist for an interval longer than about
  69 15 minutes, the next value is believed and the clock stepped or slewed
  70 as determined by the <tt>-x</tt> option. The usual reason for this
  71 behavior is when a leap second has occurred, but the reference clock
  72 receiver has not synchronized to it. When leap second support is
  73 implemented in the kernel, the kernel implements it as directed by the
  74 NTP daemon. If this happens and the reference clock source
  75 resynchronizes correctly within 15 minutes, the transient misbehavior of
  76 the source is transparent.
  77
  78 <p>It has been observed that, as the result of extreme network
  79 congestion, the roundtrip delays can exceed three seconds and the
  80 synchronization distance, which is equal to one-half the roundtrip delay
  81 plus the error budget terms, can become very large. When the
  82 synchronization distance exceeds one second, the offset measurement is
  83 discarded. If this condition persists for several poll intervals, the
  84 server may be declared unreachable. Sometimes the large jitter results
  85 in  large frequency errors which result in straying outside the
  86 acceptable offset range and an eventual step or slew time correction. If
  87 following such a correction the frequency error is so large that the
  88 first sample is outside the acceptable range, the daemon enters the same
  89 state as when the <tt>ntp.drift</tt> file is not present. The intent of
  90 this behavior is to quickly correct the frequency and restore operation
  91 to the normal tracking mode. In the most extreme cases
  92 (<tt>time.ien.it</tt> comes to mind), there may be occasional step/slew
  93 corrections and subsequent frequency corrections. It helps in these
  94 cases to use burst mode when configuring the server.
  95
  96 <hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
  97 href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
  98 </address></a></body></html>
  99