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,208
  • 8
  • 24
  • 42
  • It will be software keeping time when not connected who t it? I'd say time keeping software is inherently accurate. – Jivings Aug 01 '12 at 23:23
  • 1
    You talking about a 10 minutes maximum at worst per year(extreme temps of -20 and lower / +60 and higher)(optimized for 20degrees operation) . Its not that bad. A real-time clock now a days is only used for atomic time keeping.. like.. very precise mathematical functions that need to measure execution time or something hectic. Allot of devices drop 32khz crystal because oscillators are good enough for generating RF signals or Video signal without serious complications. – Piotr Kula Aug 02 '12 at 12:40
  • @ppumkin Do you have any sources for this? I was kinda expecting less accuracy due to the reasons that Chris Stratton mentioned (missed interrupts and such). –  Aug 02 '12 at 12:41
  • 1
    Sorry- Just my general knowledge in the field and experience of using oscillators instead of crystals. Missing interrupts is going to be mega extreme! If it were that bad everybody would not be doing it. – Piotr Kula Aug 02 '12 at 12:44
  • This question is really more about Raspbian than about the Pi itself. And the idea of keeping a Pi running continuously for over a year is so unlikely that it makes the above statistics insignificant by comparison to what happens during reboot. – SDsolar Jun 19 '18 at 03:39

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
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
  • 11,847
  • 9
  • 46
  • 74
  • 3
    Kevin Sangeelee has posted a detailed write up of adding a RTC to the Raspberry Pi http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ – Steve Robillard Aug 01 '12 at 23:37
  • 1
    Another alternative for a non networked Pi is using radio time signals as discussed here http://www.designspark.com/de/content/atomic-time-raspberry-pi – Steve Robillard Aug 01 '12 at 23:52
  • +1 For hooking up an RTC to GPIO if more accurate time is needed. Maybe even an atomic receiver.. :-) nice suggestion! – Piotr Kula Aug 02 '12 at 13:07
  • I have no great expertise here, but I'd like to say that "radio station WVVB or CHU" is a more accurate descriptor than "atomic radio receiver," or similar. :) Good suggestion. For those within reach of CHU there's even c code out there to pull in the audio and parse the time. – Tai Viinikka Jul 25 '13 at 00:50
  • Here is the updated link for my previous comment – Steve Robillard Jun 19 '18 at 04:04
  • There are VLF receivers for this - the kind they use in clocks. They would have a great advantage if the clock gets set by them early in the boot process. --> Alert: WWV is on 60 KHz while the rest of the world uses 50 KHz. Amazon has both versions available. Caveat emptor. Make sure you know what you are buying before beginning the project. – SDsolar Jun 19 '18 at 18:53
  • @SDsolar, Unfortunately radio time service isn't an option in Australia http://www.measurement.gov.au/Services/Pages/RadioClocksinAustralia.aspx so we get to choose between GPS or internet time. – John La Rooy Jun 19 '18 at 21:28
  • 1
    OK, then here is a GPS solution: https://raspberrypi.stackexchange.com/questions/68816/how-can-i-set-up-my-g-mouse-usb-gps-for-use-with-raspbian – SDsolar Jun 20 '18 at 01:29
9

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,208
  • 8
  • 24
  • 42
  • 2
    I can confirm that. Without internet connection or RTC date and time from raspberry is useless. – Łukasz Jakubek Jun 19 '18 at 14:24
  • There are VLF radio receivers with clock demodulators in them. For example, Here is one tuned to 60 KHz can hear WWV in Colorado all over North America. https://www.amazon.com/CANADUINO-60kHz-Atomic-Clock-Receiver/dp/B01KH3VEGS These are the same modules they use in some clocks. They work with Arduino and Pi. – SDsolar Jun 19 '18 at 19:36
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

chaosdelphin
  • 11
  • 1