21

I realize that since Raspberry Pi doesn't have a hardware real-time clock built in, some issues with accurate timekeeping may present themselves, even when persistence across reboots is not a requirement.

This can largely be mitigated by running a NTP daemon that will continuously correct the local time, but NTP is not an option if the Raspberry Pi is not connected to a network.

So if I leave a Raspberry Pi turned on with accurate time in the beginning, how much should I expect the reported time to drift from the actual local time?

And how about between reboots?

SDsolar
  • 2,378
  • 8
  • 26
  • 43

4 Answers4

10

There are really two issues:

1) The accuracy of the oscillator itself - which has variables such as uniqueness, age, temperature, etc. A quick catalog perusal suggests typical microprocessor clock crystals are on the order of +/- 10-100 parts per million

2) If there is anything which might cause timekeeping errors relative to the crystal oscillator. That would be things like missed interrupts, or transition issues if the clock used is after a PLL multiplier - or affected by clock throttling (if it's used).

Incidentally, NTP unless very well implemented can actually make precise self-relative timing worse in the short run, since it means the local clock can be changed to be consistent with an external authority, rather than remaining consistent with itself.

Chris Stratton
  • 993
  • 5
  • 11
10

Interpreting the question to be asking about a Raspberry Pi running Raspbian.

The OS is the dominant influence in how the Rapberry Pi keeps time.

Answer: Without an external source, the internal clock is highly unpredictable in terms of keeping time on its own.


Recent case studies:


This is a plot from a Raspberry Pi 3 B datalogger which suddenly lost utility power for about an hour:

enter image description here

You can clearly see that when power came back on, it booted and restarted the data logging.

But the Raspbian clock jumps back in time.

Then you can see it jump forward to the correct time as soon as it gets an update from time.nist.gov


The National Bureau of Standards recommends using time.nist.gov because it is a smart URL that finds the quickest and most accurate time available. Both Linux (ubuntu and Raspbian) and Windows default to pools which can be many hops away from the Master Clock.

How do I set Raspbian to use the primary time server time.nist.gov?


Here is a newer plot from the same system again.

Since it interrupted yesterday (see plot above) I used sudo init 0 to shut it down properly, in order to image the SD card with Win32DiskImager on a PC.

It takes a while, as can be seen here.

enter image description here

In this one you can see Raspbian initially restarted its clock right where it left off. It looks like it had logged good data (jumps up) within a minute.

Then it shows what happens when it receives the time update. It jumps forward to the right.

The amount it jumps forward (a couple of hours) is time that was missed by Raspbian while the SD card was being imaged.


Here's a surprising twist.

The system simply froze up. Both red and green lights on, no flickering.

Announced (using espeak) within minutes by the main server's ping-based cron job which monitors the data loggers for just such an occurrence. So it wasn't off more than a few minutes.

Pulled power for a few seconds. Rebooted it - LEDs look normal.

Here is how this glitch affected the data logging:

enter image description here

The Raspbian clock jumped forward by 2 hours when the system was rebooted.

Then the time update from time.nist.gov sets it back.


Answer: Without an external source, the internal clock is unpredictable in terms of keeping Real Time on its own.


How do I set Raspbian to use the primary time server time.nist.gov?

SDsolar
  • 2,378
  • 8
  • 26
  • 43
9

It will depend on the crystal they used, maybe 10ppm or so. You can't really count on it unless it is specified somewhere though. You may be able to use GPS if not connected to a network. Otherwise a RTC chip can be added.

You'll need something better than just software time if there is a chance the RPi can lose power or crash.

I hope to be hooking up a RTC to the GPIO sometime soon

John La Rooy
  • 12,005
  • 9
  • 48
  • 77
1

We faced the same problems as you. Setting up a real-time control system with a Raspberry Pi. We found a HAT for it that works with an accuracy of 10 ns. This realtime HAT can do even more. It is equipped with Time-Sensitive Networking (TSN) capabilities and can sync with PTP. The Raspberry Pi is no longer a hobbyist board with this HAT. Here is the opensource GitHub repository link of the HAT, there you can guess what this beast is capable of. https://github.com/InnoRoute/RealtimeHAT