[ntp:questions] System clock going slow/fast with ntpdate MIPS

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Oct 27 17:24:21 UTC 2016


On 2016-10-26 23:20, Deepak Gaur wrote:

> I have board with MIPS 34Kc processor and linux-2.6.29 with
> CONFIG_HZ_250=y set in kernel configuration (i.e 250 timer interrupts
> per 1 real second in /proc/interrupts).

Is the kernel built to run VSMP/SMVP, SMTC, or AP/SP mode?
Each of these configurations virtualizes the available processor: as two cores,
multiple threads, or as a UP with an AP.
Anything else running at the same time will affect the available processor time
and virtual time seen by the kernel, just as running under a VM does.
Are other kernel clock configurations possible, such as tickless or 1kHz, that
could give higher precision time?

> When I try to synchronize time using ntpdate command, the time gets
> synchronized. This resync is being done every 5 min using cron. The
> clocksource is set to jiffies and is the only source available.
> After some time (1 hr and more) the system clock (kernel/software)
> sometimes starts slowing down and sometime goes fast. System time
> increments very slowly i.e 1 sec on system takes 8-9 real seconds (as
> per wrist watch) or fast 2 sec in 1 real second.

What else is running on the system that uses amounts of CPU time?

> ntpdate uses ntp_adjtime()/adjtimex() GNU libc system call for
> changing system clock and can change it but by a very small amount.

Or steps if it appears more than 0.5s.

> But the issue is it is changing system clock so much that other
> application have started behaving erratically, timers are not
> expiring in required time etc.. and once the system clock has slowed
> down/fast it remains in that state.

What version of ntpdate are you using, with what arguments, and what are your
ntpdate time sources?
Are your time sources decent quality and close by on the network, or is it
something like a MS PDC, that itself may be unsynced or synced to a poor
quality source, such as its default time.windows.com?
What do your ntpdate logs say the round trip delay is, and how is it changing
the time - by stepping or slewing?

If your system clock crystal or network sources are poor quality, ntpdate may
be stepping the time by >0.5s every 5 minutes, which would explain the erratic
timekeeping.
System timing should not be affected, as it should be using periodic interval
timers, but may have to use delay loops for shorter periods as your timer
resolution is so poor.
You can't expect much from a system if it has only a motherboard crystal and
4ms resolution timing.

> Please help me in understanding this behaviour of NTP with MIPS Linux and
                                                     ntpdate
> possible fixes if any. Is it a kernel bug or a configuration issue?

It is a system management issue - ntpdate is intended to be used daily or
every few hours to keep time roughly correct when it is run - similar to
Windows time service. The ntpdate man page advises every hour or two.
You should start by running ntpdate daily in query only -q or debug -d mode
against multiple time sources both to evaluate the rate or frequency drift
of your system clock and the quality, reliability, and stability of your
time sources.

Your system was designed for an era where wristwatches were used to set the
time, possibly provided in unspecified ASCII formats (like asctime or SMTP)
from a server using the daytime protocol, and may have been synced daily to
the nearest second, using rdate and the time protocol to a local server,
possibly over dailup  telephone lines.

The ntpd daemon disciplines system time but requires decent precision system
clock sources in the MHz, and stable high quality time sources fairly nearby
on the network. Lower delay samples are known and assumed to be higher
quality time, from observations made of good time sources over networks.

You would get much better quality time with a cheap modern retail SoC system
like a BeagleBone Black or RaspberryPi which runs ntpd, and can have a GPS
board added for more accuracy.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the questions mailing list