1

I am using a RTC. I read the documentation for this module that it will lose a second every 24 hours. So, I assume i have to update it myself. After Googling I was drawn to this solution:

hwclock --systohc

But then I read elsewhere that the system clock may not be accurate. It will only be accurate if it has an internet connection to get the latest date/time. Whilst this is obvious I cannot rely on it.

So, what I would like to go is say every 6hrs I try myself to get the NTP time. If successful then i call

hwclock --systohc

If not successful, try once every 10 minutes.

how can I access/call NTP time from the command line?

  • 3
    If you are using a "module that it will lose a second every 24 hours" you have the wrong module! If you have a supported RTC and install it correctly it will resync to correct any minor differences from reference time sources. See https://raspberrypi.stackexchange.com/a/104139/8697 – Milliways Jan 03 '21 at 11:15
  • @Milliways Hi, yes it is poor RTC. I read the product description after buying it. Was only about £4. Thanks for the link. It is what I needed. –  Jan 03 '21 at 11:26
  • 1
    RaspiOS doesn't have NTP. It has systemd timedatectl and systemd-timesyncd. Those two implement SNTP rather than NTP and infrequently poll a timeserver to sync the clock. If you want ntpd and ntpq you have to jump through hoops to disable that systemd junk. – Dougie Jan 03 '21 at 13:19
  • @Dougie Yes. I have come across that now. i may delete this question soon. But just wanted to save 'thanks' –  Jan 03 '21 at 14:50
  • @Dougie: If you look at the code in the systemd timekeeping function, it seems at odds with your comment. But perhaps things have changed? REF – Seamus Jan 04 '21 at 00:30

2 Answers2

2

I'm sure I do not completely understand your question:

  • You seem to be asking how to use ntpd to update your el cheapo RTC.

  • You have seemingly found how to update your RTC from the RPi's system time, and I think @Milliways comment has also addressed that point.

  • You haven't stated your accuracy requirements, and it seems that you may not be entirely clear on whether or not the RPi's default SNTP is capable of meeting your requirement.

  • And finally, perhaps in further confusion, it has been opined that running ntpd has been made awkward by systemd-timesyncd.

All that said, the following is offered to help sort some of this:

1. NTP vs SNTP on Raspberry Pi

A SE Q&A from 2018 covered some of the details of how NTP (and ntpd) came to be dropped from the RPi, and replaced with SNTP. It also offers a few words on the timekeeping function in general on RPi. AFAIK, the two answers there are still correct. Reading through this Q&A may advise your course of action. This document provides a summary of the diffs between NTP and SNTP

2. Accuracy Expectations

Some measurements on the RPi's internal clock, and included in this Q&A suggest that your RTC - despite its el cheapo rating - will provide far better accuracy than the RPi system clock! A referenced article supports a claimed accuracy (using NTP) of "less than 100msec", but pay attention to the caveats.

This suggests that even with some network instability/outages your RTC should be able to maintain your RPi's system clock to considerably less than 1 second error. If you need reasonable accuracy, and you suffer network outages, I'd say your RTC was a good investment of £4. If you need better than that, consider investing in a GPS - or a better RTC.

3. Offing systemd-timesyncd

As noted in # 1 above, RPi's default timekeeping service is SNTP via systemd-timesyncd. However, you can replace the default timekeeping to ntpd, chronyd, openntpd - or any other timekeeping client you choose - without interference or hassle from systemd-timesyncd.

In fact, you don't even need to notify systemd-timesyncd - simply install ntpd, chronyd or openntpd, and systemd-timesyncd will abide by your choice. In other words, if systemd-timesyncd detects one of these services running, it will stand down - it automatically defers to your choice. I'm still astonished at the politeness of this... if all software were this polite!

You may verify this for yourself as follows:

$ systemctl cat systemd-timesyncd | less

Note the last several lines of the output listing:

# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

4. Manual Updates to System Time

You asked:

how can I access/call NTP time from the command line?

AFAIK, this is not possible, but the (now deprecated) ntpdate or the ntpsec-ntpdate utilities may accomplish your objective by setting the system time from an NTP server. They may be installed on RPi in the usual way using apt. It's not clear to me why you want to do this manually - unless you have no Internet connection at all, but if you do, perhaps this will work.

If you're into manually updating your system clock - or have no Internet connection, this may interest you:

$ date -s 'YYYY-MM-DD HH:MM:SS'

see man date if you need the details

In Conclusion

Hope this helps - let us know if you have further questions.

Seamus
  • 21,900
  • 3
  • 33
  • 70
  • Thanks for such a comprehensive answer. I admit this is new to me. In essence I know I need to use a RTC to keep accurate timekeeping. When I look at the specs for various RTCs it tells me that there is an error range over a period of time. I wanted to know if that 'error' is corrected and if so how. The comment by @Milleways gave me my answer I needed. You have answered my poorly described problem/question –  Jan 04 '21 at 08:52
  • @AndrewSimpson: So - are you using the dt overlay instead of hwclock? And is your Internet service reliable - or is that the reason for the RTC? – Seamus Jan 04 '21 at 09:04
  • I am using hwclock and the internet is unreliable –  Jan 04 '21 at 09:25
  • 1
    @AndrewSimpson: That sounds like a good approach. You could add hwclock to your crontab to keep it as fresh as possible - that would give you some advantage during the outages - and it doesn't require "manual intervention" :) – Seamus Jan 04 '21 at 18:35
0

I'd suggest the key is to consider "What function is the RTC adding?"

In most systems (RPi included) the response to system calls such as time() (commonly known as "wall time") comes from a variable maintained in the kernel. Implementations differ, but normally this is incremented based on a timer interrupt tied to the main CPU clock/crystal.

The RTC is not involved in this process.

Inaccuracies in the crystal, both gross frequency offset, and temperature/age related, impact how this counter evolves over time i.e. "How long is a second?", "Is my clock running fast or slow?". NTP (and similar) can use external references to calibrate out the gross offset in the crystal, and if connection is maintained, also compensate for variations in the offset. This avoids long term drifts in the results from time().

The RTC is not involved in this process either.

Where the RTC is involves is the initial setting of the kernel variable.

Without an RTC, when the kernel starts it has to retrieve the initial time over the network. If that isn't possible, many system default to the start of the UNIX time epoch, giving Jan 1 1970 as the result from time().

With an RTC, the network lookup isn't needed, and instead the kernel "wall time" variable is set from the RTC. Once running, and especially if you have access to accurate time over the network, the kernel will normally apply periodic updated to the RTC time from the kernel variable.

The purpose of the RTC is therefore just to maintain a good estimate of time when the computer is turned off.

It has to do this in an extremely low power fashion (as it will be running off a battery), which in turn tends to limit accuracy. An example of a very good RTC is the Dallas DS3231. This commits to better than 2ppm for 0C-40C which equates to 200ms/day. For a cheaper RTC, 1s/day is perfectly normal.

The difference should have zero impact on the result of time(). It merely means that if the RPi is turned off for a week, on restarting one will give you initial time good to about 1.4s, whilst the other could be up to 7s out. In both cases, once you get network access, the wall clock will be updated to the correct value.

In the event of no ongoing network access, after an initial NTP calibration, the kernel clock will generally still give you a better result than an RTC when the system is running. If you really have to have an accurate clock without network (or GPS) access then look to using a TCXO to maintain time after an initial set. Switch out the X1 Oscillator on a RPI 2/3

colintd
  • 357
  • 2
  • 10