[ntp:questions] very slow convergence of ntp to correct time.

Unruh unruh-spam at physics.ubc.ca
Sun Jan 20 18:15:02 UTC 2008


david at ex.djwhome.demon.co.uk.invalid (David Woolley) writes:

>In article <T1200833223 at ex.djwhome.demon.co.uk.invalid>,
>david at ex.djwhome.demon.co.uk.invalid (David Woolley) wrote:

>> Pop corn spikes of less than 128ms are not ignored in the default
>> configuration.  If, as I suspect, you only have one time source, they

>However I forgot that only the best of the last 8 samples is used.  Sample
>quality is decreased by being old (the clock is assumed to have drifted
>since it was made).  I think it also decreased by having a large delay
>value.  On the other hand, you are dealing with quite small delay 
>values.

50 times the typical delay is surely not small even if it is "only" 5 ms. I
suppose I am trying to see what the best discipline I can squeeze out of
the system is. On a PPS slaved system it seems to be 2-3usec. On a  local network
it looks like it should be 20-30usec (Yes, a not overloaded network or
computer).  On a distant network, 200-300us. Clearly if the computer is
overloaded (lost or delayed interrupts, contention,...) or the network is,
that accuracy will degrade. However the speed with which such events are
corrected  (eg a lost tick) is also an important attribute of the system.
 If it takes hours to correct that is not good either.




More information about the questions mailing list