4

I'm working on a Raspberry Pi project, in which date and time are the most important factors. So, I want them to be very accurate.

I know there are two methods to configure the Raspberry Pi's date and time, which are using an RTC module or auto update date and time from the Internet.

The problem is that I can't fully depend on the Internet, since an Internet connection on my country is not stable.

I want to combine these two methods, so that the RTC will do the job, but a small Python function will check the Internet for any time changes. Since in my country each year the time changes one time an hour up and one time an hour down.

Peter Mortensen
  • 1,984
  • 2
  • 14
  • 17
Dani
  • 471
  • 1
  • 5
  • 17
  • 1
    will your raspberry pi run the whole time or will it shutdown quite often? If it keeps running all the time you just connect to the internet once restart your ntp server and the time will be set. You can remove the internet cable and the time will remain unchanged and reliable – Shan-Desai Jul 26 '16 at 10:39
  • it will normally run the whole time, I'll shutdown it just in case of maintenance. So according to your answer I can completely exclude RTC Module. – Dani Jul 26 '16 at 10:49
  • RTC are useful for places where you do not tend to have internet access. If you are indoors and if you have NTP servers around you can make it easier to sync times. But if you want to be sure use Both RTC and NTP together will maintain a good time synchronized system – Shan-Desai Jul 26 '16 at 10:54
  • You'll need to define what *very accurate* means for you. All depends on the answer to that. – Ghanima Jul 26 '16 at 10:56
  • That was my main question: how to use them both together? suppose the RTC got corrupted how could I guide the rpi to know that it must choose internet connection.. and vice versa... – Dani Jul 26 '16 at 10:57
  • “_in my country each year the time changes one time an hour up and one time an hour down._” The internal Linux clock is kept in [UTC](https://en.wikipedia.org/wiki/Coordinated_Universal_Time), so it is not affected by local time rules. When converting system time to local time, the DST correction is applied automatically, using the local copy of the [timezone database](https://en.wikipedia.org/wiki/Tz_database): no Internet needed. The Internet connection is only needed for updating the database itself, when the _DST rules are modified_ by political decisions. – Edgar Bonet Jul 26 '16 at 15:34
  • 1
    Actually there is another way of setting the time on the Raspberry Pi: use a GPS module. Depending on the accuracy you want, you can get a cheap USB GPS module for under $20, and then use gpsd to talk to it, and NTPd to keep the clock synchronised to the GPS module. (That is more than enough to keep the clock accurate to the second - if you want closer to millisecond accuracy, you may need to invest in a GPS module with a PPS output; such things [do exist](https://store.uputronics.com/index.php?route=product/product&product_id=81) specifically for the Raspberry Pi, but are more expensive.) – psmears Jul 27 '16 at 13:22
  • @psmears good idea. Why don't you make that approach into a full answer? It certainly adds value. – Ghanima Jul 28 '16 at 20:45
  • If you have an internet connection you can use the atomic clock: https://raspberrypi.stackexchange.com/questions/68811/how-do-i-set-raspbian-to-use-the-primary-time-server-time-nist-gov/68812 – SDsolar Sep 25 '17 at 07:15

4 Answers4

7

What I want to do, is to combine these two methods

Then all you have to do is install an RTC.

The NTP daemon which is used to set the time on the pi is also commonly used on systems with a clock to keep it synchronized with the real world and occasionally correct the small amount of "drift" standard computer clocks are often prone to.

The daemon can be annoying initially if it cannot make an internet connection to verify and correct the time since it reports this to the kernel as a serious problem (i.e., one which gets spit to the console), but this does not persist and does not cause any issues beyond that unless something is bound to its success, which by default on Raspbian nothing is as far as I am aware (I think it is only a genuinely serious problem when clustering or in other contexts where physically separate systems are intimately bound and synchronizing data at a high rate -- in which case they should sync clocks as soon as they link).

Although it is perhaps poorly designed in other ways from a user perspective, it at least has copious documention (you can get the current version with ntpd --version), parts of which you may wish to read through. Don't get your hopes up about making it less annoying, but it can be tweaked with regard to various parameters such as how quickly it updates the clock when a discrepancy is found.

Beware the difference between the system time, and the hardware time; the system time is actually what is most significant for general operation, but if the hardware time is not also updated, the system time will need correcting again at next boot, which can cause certain things to complain if it is behind and you do a quick reboot (these things will notice timestamps that appear to be in the future).

It sounds like Raspbian (or ntpd itself) will keep the system time and the hardware clock synchronized (see comments below). If this turns out not to be the case for you it is easy to solve (see man hwclock).

goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • 1
    In general I agree with the answer, but my experience is the system updates the RTC when `ntp` is also present. It also adjusts automatically for Daylight Saving changes (assuming locale is correct). I have been using RTC on one of my Pi for a year, and the time remains accurate within 1 sec. While you can set/adjust the time it automatically corrects to `ntp`. I recommend you get a RTC using ds3231 which runs on 3.3V and also select one with a Lithium cell rather than a super-capacitor. – Milliways Jul 26 '16 at 11:51
  • I'll take your word for it and correct that then. I was assuming this was left out as something system specific -- which perhaps it is, and Raspbian is configured to update a hardware clock if present, but in any case it amounts to the same thing; I use ntp on systems with a clock but actually haven't paid attention to whether the hw clock is updated by it. – goldilocks Jul 26 '16 at 12:00
  • So I can conclude that if I'm installing RTC module, raspbian will stay depends on the RTC time, and when there is an internet connection it will automatically synchronize the RTC time itself, and if there is no internet connection it will normally depends on the RTC time, Is this correct? – Dani Jul 26 '16 at 13:20
  • Yes. That's how it's supposed to work. The ntp servers used for updating (presumably) work that way too. I believe there are distributed systems that rely on this for millisecond level precision, and the way the network as a whole is supposed to work is the higher tier servers are the most reliable reference points, and somewhere in there there's probably a few with access to caesium clocks (i.e., zero drift) and such. – goldilocks Jul 26 '16 at 13:25
4

One thing to consider here are the requirements, that is: what is very accurate?

Without a dedicated hardware clock (RTC) the Pi runs a STC as a clocksource derived from the GPU core clock. Once date and time are set - either manually or by means of ntp they will be drifting off just a little as the frequency source is supposed to clock the chip not provide highest accuracy timing. Without regular resyncing with another source (ntp or an RTC) it will drift a few seconds a day.

So, without adjustments or syncs with other sources, it will drift this many seconds in 24 hours

The Raspberry Pi does not ship with a TSC nor HPET counter to use as clocksource. Instead it relies on the STC that Raspbian presents as a clocksource. Based on the source code, “STC: a free running counter that increments at the rate of 1MHz”. This means it increments every microsecond.

The listed source finds a deviation of about 40 ppm (parts per million) or approximately ~3.52 s/day. If one were to believe that drift to be constant over time there is probably a way to adjust for it, e.g. using adjtimex. However beware that the clocksource might change slightly with time and even more so with temperature.

Again, depending on the required accuracy and availability of network connection to resync using ntp the answer might very well be that it'll work out just fine for the application intended.

Source: https://blog.remibergsma.com/2013/05/12/how-accurately-can-the-raspberry-pi-keep-time/

Inspired by psmears' comment about using a GPS module to obtain a time signal: there's another way to go without (reliable) internet. Radio time signal stations, best known from radio-controlled clocks, transmit a time code by a radio transmitter. Modules to interface to microcontroller boards or the Pi exist (at least for DCF77). Local availability of the signal might be subject to coverage but longwave radio frequency travels quite a distance, e.g. DCF77 covers most of Europe. Here's a list of existing stations.

Ghanima
  • 15,578
  • 15
  • 58
  • 113
  • “_If one were to believe that drift to be constant over time_” It is almost, but not quite constant: if you correct for the _average_ drift, your clock accuracy will be dramatically improved, yet not perfect. There is no such thing as perfect accuracy. “_there is probably a way to adjust for it._” Sure there is: it is called [adjtimex](http://linux.die.net/man/8/adjtimex). – Edgar Bonet Jul 26 '16 at 15:54
  • Thanks for pointing it out (it's also in the linked source for the interested reader). The measures taken all depend on the accuracy needed by the OP but as of now all we know is *very accurate*. – Ghanima Jul 26 '16 at 16:01
2

If you have installed RTC timedatectl will show status of RTC as well as system. 

      Local time: Wed 2016-07-27 11:27:30 AEST
  Universal time: Wed 2016-07-27 01:27:30 UTC
        RTC time: Wed 2016-07-27 01:27:31
       Time zone: Australia/Sydney (AEST, +1000)
     NTP enabled: no
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2016-04-03 02:59:59 AEDT
                  Sun 2016-04-03 02:00:00 AEST
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2016-10-02 01:59:59 AEST
                  Sun 2016-10-02 03:00:00 AEDT

sudo hwclock -r will show RTC time and delta

Wed 27 Jul 2016 11:29:24 AEST  -0.404345 seconds
Milliways
  • 54,718
  • 26
  • 92
  • 182
0

Do know that Linux internally stores and computes dates and times based on UTC (otherwise known as GMT), and that local Daylight Savings Time (DST) changes (you called them changing "an hour up" and "an hour down") are not handled by synching the time with the Internet, since UTC is continuous and doesn't change with DST. DST handling, and converting to/from UTC in general, is done using a timezone database. Your locale is almost certainly in Raspian's timezone database. I would be very surprised if it was not.So as long as your /etc/timezone file shows your locale, you won't have to worry about DST.

Tom H
  • 1