[ntp:questions] ntpdate refusing ntp.nmi.nl

Unruh unruh-spam at physics.ubc.ca
Sat Jan 10 02:32:38 UTC 2009


David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>Folkert van Heusden wrote:
>> 
>> Ok so the root dispersion is not too high if I understand you correctly
>> (well it would be better if it were lower)

>The root dispersion is consistent with having a very old reference time. 
>  The reference time is too old, which means the root dispersion is too 
>high.  It is the high root distance (which includes the root dispersion) 
>that is causing the server to be rejected.


>> The systems I checked that sync to this server (and others, of course)
>> seem to ignore it:
>> 
>> *GENERIC(0)      .DCFa.           0 l   55   64  337    0.000   -2.421   2.390
>> +adsl.remco.org  .GPS.            1 u  504 1024  377   19.581    3.159   0.188
>> ...
>>  ntp.nmi.nl      .IRIG.           1 u  535 1024  377   12.146   52.565   0.044
>> 
>> 
>> The reason that I keep on going on this system is that I would like to
>> have them get it to also work with ntpdate and such and not only the
>> windows implementation. The reasons for them to fix it I come up with is

>It is not working with nptd, either.  There is no character in front of 
>it, which means that it is being rejected.  If you do rv for the 
>association, you will see a code indicating that the the distance is too 
>high.

>> now:
>> - root dispersion too high

>and therefore root distance is too high, and therefore it is rejected as 
>a source.

>> - offset too high; 52ms (tried from ADSL, cable and SDSL connected

>The very large root distance would make 52ms highly acceptable, if the 
>clock weren't being rejected.  52ms is well within the, nearly, 4,000ms 
>uncertainty.

>In reality, this figure could either represent that it really has been 
>unsynchronised for three days, but is drifting at rather less than 15ppm 
>(and 15ppm is really rather pessimistic), or that you have a calibration 
>error on your PPS input.

No, it was last synchronized from IRIG then. Since then it is supposed to
have been synchronized from the H masers they keep as a primary world time
source for Neatherland's UTC time source.  I assume this is being done by
something other than ntp (eg a separate oven controlled clock source driven
by the world TAI standard)and thus ntp does not see it, and thinks that the
last time the local clock was synchronized was a week ago, while actually
the local clock is continually synchronized to far far better than ntp
could ever hope to do it. But noone told ntp.


>>   systems, synced to GPS+PPS, DCF77, MSF and systems on the internet)
>> - reference time too old

>DCF is not good for very high accuracy time.

>Someone mentioned that this machine is only intended for synchronising 
>Windows.  I don't believe that w32time performs a root distance check on 
>its servers.




More information about the questions mailing list