"Jos van de Ven" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [...] > My relative frequency is stable at about -148 ppm, so my system clock > runs too fast due to 1000 Hz setting as I understand.
It would run fast if not corrected, but I would hesitate to ascribe it to the kernel's HZ setting. > I read that -148 ppm is not a good clock; should be no more than > absolute 50 ppm. Why not? It's well within the limit of what NTP can correct for. > Is it the kernel that's making my clock bad or just also bad hardware > or a combination of both? You don't know. I don't, either. > What if I do a tickadj, so the frequency is stable at about 0 ppm, > do I have a better clock then? I don't think so, but other people > querying my server, may think it is very reliable. It could correct for a wider range of transients. If -150 PPM is your starting point, an extra disturbance of +350 PPM pushes you over the limit. If you pre-correct, it could deal with disturbances up to +500 PPM. On the other hand (side), though, you could stand a -650 PPM disturbance in the first, and 'only' -500 PPM in the second case. However, even 350 PPM is absurd. If you saw variations like that, I'd recommend not leaving your computer out in the desert at night. And those other people should *never* see your uncorrected frequency offset. Even loading this value from the drift file would correct for it. Groetjes, Maarten Wiltink _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions