[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