The following comments are excerpted from the html/debug.html page that comes with ntp 4.0.99k23:
---- begin various excerpts ---- If the initial time error is less than 1000 s but greater than 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. However, if a step adjustment, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values. If, as discussed later in this page, for some reason the hardware clock oscillator frequency error is relatively large, the time errors upon first startup of the daemon may increase over time until exceeding 125 ms, which requires another step correction. However, due to provisions that reduce vulnerability to noise spikes, the second correction will not be done until 900 s have elapsed since the last adjustment. When the frequency error is very large, it may take a number of cycles like this until converging on the nominal frequency correction. After this, the correction is written to the ntp.drift file, which is read upon subsequent restarts, so the herky-jerky cycles should not recur. Once the daemon has set the local clock, it will continuously track the discrepancy between local time and NTP time and adjust the local clock accordingly. There are two components of this adjustment, time and frequency. These adjustments are automatically determined by the clock discipline algorithm, which functions as a hybrid phase/frequency feedback loop. The behavior of this algorithm is carefully controlled to minimize residual errors due to network jitter and frequency variations of the local clock hardware oscillator that normally occur in practice. However, when started for the first time, the algorithm may take some time to converge on the intrinsic frequency error of the host machine. The frequency tolerance of computer clock oscillators can vary widely, which can put a strain on the daemon's ability to compensate for the intrinsic frequency error. While the daemon can handle frequency errors up to 500 parts-per-million (PPM), or 43 seconds per day, values much above 100 PPM reduce the headroom and increase the time to learn the particular value and record it in the ntp.drift file. In extreme cases before the particular oscillator frequency error has been determined, the residual system time offsets can sweep from one extreme to the other of the 128-ms tracking window only for the behavior to repeat at 900-s intervals until the measurements have converged. In order to determine if excessive frequency error is a problem, observe the nominal filtoffset values for a number of rounds and divide by the poll interval. If the result is something approaching 500 PPM, there is a good chance that NTP will not work properly until the frequency error is reduced by some means. A common cause is the hardware time-of-year (TOY) clock chip, which must be disabled when NTP disciplines the software clock. For some systems this can be done using the tickadj utility and the -s command line argument. For other systems this can be done using a command in the system startup file. If the TOY chip is not the cause, the problem may be that the hardware clock frequency may simply be too slow or two fast. In some systems this might require tweaking a trimmer capacitor on the motherboard. For other systems the clock frequency can be adjusted in increments of 100 PPM using the tickadj utility and the -t command line argument. Note that the tickadj alters certain kernel variables and, while the utility attempts to figure out an acceptable way to do this, there are many cases where tickadj is incompatible with a running kernel. Normally, the daemon will adjust the local clock in small steps in such a way that system and user programs are unaware of its operation. The adjustment process operates continuously as long as the apparent clock error exceeds 128 milliseconds, which for most Internet paths is a quite rare event. If the event is simply an outlyer due to an occasional network delay spike, the correction is simply discarded; however, if the apparent time error persists for an interval of about 20 minutes, the local clock is stepped to the new value (as an option, the daemon can be compiled to slew at an accelerated rate to the new value, rather than be stepped). This behavior is designed to resist errors due to severely congested network paths, as well as errors due to confused radio clocks upon the epoch of a leap second. ---- end various excerpts ---- There are cases where the hardware clock cannot be adjusted far enough, and no matter how long you wait, ntpd may continue to have to perform step adjustments. In any case, until the clock frequency is adjusted, ntpd may make occasional step adjustments if the clock is off by more than 125 ms. -- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
