Using Linux RTC as a Reference Clock?

On normal PCs, the RTC is backed by the standard BIOS RTC, on 32.768 kHz crystal without compensation. Due to its heavy drifting, the RTC is only used to set the system time on boot. But for some setups, the time provided by the RTC clock is reasonably accurate, when…

  • The RTC is backed by a good electronic circuit, or has been modified to be one.
  • The RTC clock has an external mechanism for time synchronization.
  • The clock is kept by an external hardware device with good accuracy, but registered in the Linux kernel as a standard RTC device.

The Linux kernel supports more than 50 RTC chips over common bus standards such as I2C or SPI, and it’s not uncommon for an external circuit to be plugged on a Linux-based system and powered by an RTC driver already presented in the Linux kernel.

Another important application is virtualization. Normally, time can be read from the RTC on the virtual machine, but cannot be written. The virtualized RTC device copies the time from the host system time. And in fact, on the host, time is often already synchronized from the Internet with NTP. In fact, for most of the “cloud servers” on the Internet, it’s mostly unnecessary to request the time via public NTP servers at all.

But as we know, synchronize the system time via hwclock --hctosys would cause a sudden jump of time and destabilize the system. NTP daemon itself is still necessary to keep tracking and adjusting the system clock.

So, it is possible to use RTC time on Linux as a hardware reference clock? If not, what are some possible ways to implement it?

I searched the web and found this tutorial (Use NTP to synchronize system time against RTC). It claims 127.127.43.0 is the address of the RTC clock on Linux. A cross-check of documentation suggested Clock Type 43 it’s in fact “RIPE NCC interface for Trimble Palisade”, not related to RTC at all. Is there a similar in standard ntpd?

If it is not possible, perhaps the RTC can be simulated as a serial device, and use Type 33 Dumb Clock to feed the time to ntpd.

If you trust your RTC, feel free to use type 1 LOCAL reference clock.
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
Set it up like this:

server 127.127.1.0     # local clock
fudge  127.127.1.0 stratum 10

The fudge line is used to prevent your time from leaking into internet.

There are some RTCs that can produce PPS, which could be used in the same way GPS PPS sources are used. But keep in mind that every RTC will drift and you’ll need a way to keep it in sync. Beware of measuring things with hwclock, common RTC’s registers usually have 1 second precision, so the kernel polls them until it sees a change. That method is limited in how precise it can measure time.

I have some comparison of temperature compensated RTCs here: https://blog.dan.drown.org/rtc-comparison/

The DS3231 I tested was stable to within +/-0.085 ppm during the week of testing. That’s about +/-51ms per week. Aging of the crystal will slowly increase that error rate - https://blog.dan.drown.org/tcxo-aging-part-2/

I’ve been exploring keeping the system clock in sync by combining a local frequency standard with a network time source. I think this would be useful for NTP servers at stratum 2 or lower.