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

Andreas Baer synthetic.gods at gmail.com
Wed May 23 14:11:50 UTC 2012


I have some questions about time synchronization using ntpd involving
two external RTCs (local clock / DS3231) on Linux. Maybe some aspects
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.

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.
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 (127.127.1.0) as time resource. That
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.

Any suggestions or better solutions?


More information about the questions mailing list