On 09/02/2014 08:43 PM, Murugesh S wrote: > It would be of great help, If NTP experts can help understand the root cause > of this issue: > 1. Why and what causes the drift to reach 500.00 on certain systems.
The problem is that the frequency of the system clock deviates too much from the "real" passage of time for ntpd to be able to compensate. You said that this happens on several systems; this suggests that you have a systematic flaw in the design of those systems; either nonconforming or badly chosen crystal oscillators, or some error in the way a frequency divisor has been set up by firmware, or ... For background: ntpd operates by modulating the frequency of the system clock in an effort to minimise the offset of the system clock relative to its estimate of "true" time. But it can only do so within a range of +/- 500ppm. So the best thing would be to fix the platform such that the system clock runs at roughly the same rate such that ntpd can do its thing to minimise the residual error. I can't suggest how to go about that; you need to talk to the designers/implementers of the platform. If this can't be done, and if the frequency error is large (i.e. >500ppm) but constant, then you can use adjtimex to correct for it. See man 8 adjtimex. The idea here is to use adjtimex to make a broad-brush frequency correction and then let ntpd do its thing now that the system's frequency is within 500ppm of "true" time. You will need to first estimate by how much the frequency deviates. The adjtimex manpage describes methods for doing so. Once you have the estimate apply it and then start ntpd (after first removing its drift file). You will need to re-apply the adjtimex correction each time at boot before ntpd starts. Please fix this first, then if your 2nd and 3rd questions are still relevant come back and ask. HTH, Jan _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
