[ntp:questions] Re: NTP strategy for Linux embedded system?

Ulrich Windl Ulrich.Windl at RZ.Uni-Regensburg.DE
Wed Feb 4 14:35:08 UTC 2004


David Wuertele <dave-gnus at bfnet.com> writes:

> I am working on a consumer electronics embedded system running Linux.
> It needs accurate system time, but I'm currently seeing system clocks
> lag up to about 800PPM.  This is probably because the kernel does a
> very large amount of PIO and therefore misses many jiffy timer
> interrupts.
> 
> I would like to tune the clock using ntpd, and here is what I have to
> work with:

You cannot "tune" the clock to compensate missed interrupts caused by
overly long critical sections (read: interrupts disabled). At least
not on a long-term basis.

> 
> 1.  many units are not connected to the Internet
> 2.  all units have a real-time clock chip that I can query using an
>     I2C bus
> 3.  the real-time clock chip accuracy is better than the system timer,
>     but it is still not as accurate as Internet NTP servers

You could re-read the RT chip periodically to recover from lost
interrupts. You could also adjust the system clock towards the
real-time lock.

> 
> My idea is this: Write a reference clock driver to query the real-time
> clock chip.  This will be a big improvement over a free-running system
> counter.  If an Internet connection is available, periodically set the
> real-time clock using NTP.
> 
> Questions:
> 
> 1.  Is this a good strategy?

If you know at any time what the master clock is, and whether it has
correct time, you can do that.

> 2.  Is the SHM driver a good place to start for implementing my
>     reference clock driver?
> 3.  Setting the RTC chip has a completely different API than setting
>     the system clock.  Is there a way to easily integrate the setting
>     of the RTC into my configuration?

Linux kernel reads the RTC during boot into the system time
variables. With current PPSkit the system time is written back to
RTC. So the code is there. There is no official API for setting the
RTC.

Regards,
Ulrich

> 
> Thanks,
> Dave



More information about the questions mailing list