[EMAIL PROTECTED] wrote: >> > [EMAIL PROTECTED] log]# ntpq -p > remote refid st t when poll reach delay > offset jitter > ============================================================================== > xdcf77 LOCAL(0) 11 u 130 1024 377 5.676 1307.74 > 320.974 > x193.204.114.232 .UTCI. 1 u 137 1024 377 20.074 511.544 > 152.824 > *LOCAL(0) LOCAL(0) 10 l 44 64 377 0.000 > 0.000 0.008
You have serious problems. It looks like both of your proper sources of time are being rejected as having a false time. Also the difference between them is so high that at least one of them has to broken. (Hand tuned clocks will usually track to about 30 seconds a year, so getting out by 600ms in quarter of a day, or so, is totally unreasonable.) I'm going to guess that the DCF system isn't a real NTP server. I suspect it a machine synchronised to its local clock and having that local clock stepped to DCF on each update. A real DCF based ntp server would correct for the frequency error. NTP assumes that time errors accumulate smoothly, e.g. as the result of temperature changes or crystal aging. It is not optimised to handle time that jumps by half a second, without warning. Actually, looking back at the DCF machine, it is openly admitting that it is using the local clock. One of the problems with the local clock is that it reports an error band consistent with a real, locally attached, reference clock, so it is very easy for other machines to go outside of the error band. In this case, all three machines will have irreconcilable times. Assuming this is six hours since the last DCF read, we are talking 27 ppm. That's the drift you expect from a completely uncorrected motherboard of slightly below average quality. You should be expecting uncorrected frequency errors of more like 0.1ppm, ranging to 1-2ppm if there have been violent temperature swings. You need to install a proper DCF driver on the DCF machine, and delete its local clock line. You should probably also delete the local clock line on the other machine. Finally you need to add properly synchronised servers sufficient that you can reliably outvote any broken clock. The problem here is that all three are voting for incompatible times, so no time can have a majority. Note. This doesn't solve your large step problem, but you need to get a vaild configuration before you start worrying about that. One of the things that seems to have confused things is that you have finally introduced a well behaved NTP time source into the system. If you really can't use a proper DCF driver, you still delete the local clock on the non-DCF machine and you should hand calibrate the drift file on the DCF machine. Properly calibrated, it shouldn't drift by more than about 100ms a day. However, because it is using the local clock driver, other systems will only think it can have drifted over the time since the last time they polled, it not for the whole day, so for most of the day it is still likely to give a time that is incompatible with that from any other time server. So on balance, if you can't use a DCF ntpd driver, don't use the DCF hardware. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
