[ntp:questions] NTP synchronization using two "external" clocks (here: "Local Clock" and "DS3231-RTC")

unruh unruh at invalid.ca
Thu May 24 22:21:24 UTC 2012

On 2012-05-23, Andreas Baer <synthetic.gods at gmail.com> wrote:
> I have some questions about time synchronization using ntpd involving
> two external RTCs (local clock / DS3231) on Linux. Maybe some aspects

No, the RTC is NOT the local clock. The local clock is the system clock
itself (ie using the clock to sync itself. Amazingly it is always
perfectly on time!)

> stated in the following context are trivial or wrong but I want to
> have a kind of certainty in that topic so I'm asking it on this list.
> Situation:
> I'm in an isolated network where I want to have a single Linux machine
> serving as an NTP server. I cannot use the Linux-shipped device driver
> for the DS3231 (accessed via I2C) because this RTC is placed on a
> custom board connected to the mainboard only via USB.
> Right now I can have simple access (read/write) to the clock via
> standard time structure (struct tm) using an existing API. Of course I
> want to use the accurate DS3231 clock as primary time source for ntpd
> in this isolated server case.

You need to write an ntp  driver for that clock. 
> Possible Solution 1: "Directly feed ntpd"
> Questions:
> What is the best way to feed ntpd with the DS3231 clock data?
> I tried to understand the source code of ntpd relating the reference
> clock drivers especially 'Type 8 - Generic Reference Driver (PARSE)'
> in order to find an easy way to input properly formatted time data
> into ntpd but there seems to be no 'simple' solution and I don't have
> full understanding of all consequences.

You could also use the shm driver. Ie, you set up a little program to
read the clock every second or whatever, and place the result into a
shared memory segment and have ntp read from that shm (labeled NTP0 to
NTP4 I beleive)

> Should I write a kernel device driver which emulates a certain device
> which access is already implemented as ntpd-driver to easily configure
> ntpd for that device? What about that 'Type 33 - Dumb clock'
> interface, would that be reasonable or even possible?
> Possible Solution 2: "Sync with local-RTC"
> Questions:
> Besides directly feeding ntpd with the DS3231 clock data I could
> manually trigger the synchronization DS3231 => local-RTC and configure
> ntpd for using only the local-RTC ( as time resource. That

You midunderstant device driver 1.0, It does not use the rtc.

> would be an easy solution but I maybe found a problem. RTCs have an
> accuracy of one second and I would always hard set the local-RTC to a
> specific timestamp. This would certainly require a STEP by ntpd to
> synchronize the system time to the changed local-RTC because of
> crossing the 128ms border almost all the time, right? Of course I want
> to prevent steps as much as possible.

Nope. You have the rtc interrupt at its one second transition, and then
act as if it were a PPS device. But that is not a good way, since
many systems no longer have an rtc interrupt, but do polling instead.

The way it works is that the PPS is timed by the system clock, and the
difference between that time and the seconds transition is the offset
which is driven to zero by ntp.

But again this is really really a bad way. Setting the rtc is also a
real pain because the rtc waits .5 seconds before it sets itself. Thus
you have to write to it .5 seconds before the time you are setting it

Far better to just use the shm driver to directly write to it. Ie, read
the time from you clock, read the system time at the same time. and
write those two times to the shm (shared memory) , and ntpd will do the

> Any suggestions or better solutions?

More information about the questions mailing list