[ntp:questions] NTP time synchronization issue in linux embedded target

Jan Ceuleers jan.ceuleers at computer.org
Wed Sep 3 06:35:24 UTC 2014

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

More information about the questions mailing list