[ntp:questions] how will this effect stability
mills at udel.edu
mills at udel.edu
Thu Feb 15 10:29:36 UTC 2007
Marc & Co.,
Try the huff-'n-puff filter. This is what it is designed for.
Note the "slew always" if obsolete in NTPv4. The tinker step and -x
options can be used instead, but from the description here that would
not be a good idea. The stepout threshold and popcorn spike suppressor
are designe to resist occasional large spikes as reported and probably
would work just fine in the case cited. These were originally designed
as defense against hugh delay spikes over one second on a line to Norway
and were originally called the fjord fjilters..
Marc Brett wrote:
> On Tue, 13 Feb 2007 23:32:51 GMT, marknmbox-88 at yahoo.com wrote:
>>I am in an environment where the path to and from a
>>time server can vary from milliseconds to a second and
>>the return path may vary within the same range. The
>>transit time for each direction will be independent of
>>the time for the other. Thus the path to the server
>>may take a few mills but the return path can take a
>>second. The sum of both paths can range from a few
>>mills to seconds.
>>Will this cause ntpd problems with accuracy or
>>stability or will the ntp calculations not be
>>I have had several discussions about this and need
>>someone who is more familar with the actual
>>calculations to help me out.
> NTP assumes a symmetric round-trip travel time (RTT). For asymmetrical links,
> the time will have an error up to 1/2 the total RTT. If the asymmetry is
> predictable, you can add a constant offset to the NTP time with the 'fudge'
> If the jitter (time offset difference between two successive polls) exceeds 128
> ms, the system time will step suddenly rather than slew gently. This may affect
> your applications very badly indeed, or not at all, depending on how
> time-dependent they are. You'll have to answer that one.
> If you are very allergic to time steps, you can rebuild the ntpd daemon with the
> "slew-always" parameter set. This will avoid time steps, but may make the
> initial convergence at startup very time-consuming.
> If your network link is as bad as you describe, you may be better off with a
> primary reference of some sort on your campus. Again, you'll have to do the
> cost-benefit analysis for this.
More information about the questions