David Woolley <[email protected]> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
