Regarding to duration, there are two a little bit confusing conceptions, clock and time needs to be clarified.
As stated in on Wikipedia, RTC (Real-time clock) is used to keep track of the current time, is nothing to do with the clock described later. It focuses on the natural time (year, month, day, hour, etc.). Normally, the Integrated Circuit is used here to simulate the time flee and record the current time and date.
The clock (which is a clock signal) is a particular type of signal that oscillates between a high and a low state and is used like a metronome to coordinate actions of digital circuits. It focuses on its frequencies, and it is generated by oscillates.
The RTC needs a source of power, e.g. in PC a lithium battery is used to supply the RTC and store BIOS settings, etc.; in Revolution Pi a rechargeable super capacitor is used to supply the RTC, which is charged when the device is powering on, and will supply the RTC as the device powered off. In normal case, the SuperCap Super Cap in Revolution Pi can be full charged in several hours by power on the device and can maintain the time for about 24 hours when power off. However, the life time lifetime will depend on the environmental conditionconditions, like humidity, salinity, etc.
In contrast with Hardware, somebody maybe habitually thought that there is a software alternative one. But it seems that this is another misunderstanding in this field. The term Software-based RTC normally means the software (driver) is used to calibrate the RTC’s Hardware against drift, in another wordother words, it seems just the accuracy of hardware is improved by software. Another relevant conception maybe is the system clock or system time, which is maintained by operation the operating system. This will be described in detailed later.
As mentioned in the previous section, the operation operating system (Linux) has a system time, which is initialized at system booting, and is essentially maintained by count counting the pulse of the system clock.
The initialization of the system time can be either from the RTC hardware mentioned previously or from the network by e.g. NTP, etc. So, it’s not difficult to understand that the system time will be lost , when both time sources are not available.
In On Linux, there are some relevant services (daemons) and commands regarding to the RTC as following:
a. date : mainly used to query or read the system time, showed in graph as command between User and system time [3]
b. hwclock : mainly used to query or set the time recorded in the RTC in the graph, with --get read the time, with --set set the specific time; with --systohc set the time of RTC from system time, and with vice visa versa with --hctosys. [4]
c. timedatectl : functionally basically the same as the date command, but with better support of time zone, systemD, ntp,.etc.. etc… [2]
with With the sub command set-time to set the system time, with sub command set-ntp to enable or disable the synchronization to ntp server. with With sub command status to show the current time and setting, other sub commands are related to time zone, which is are not described in detail here.
Because of the enhancement of the ntp functions, the sub command set-time will be fail if the system time is synchronized to the NTP server, which is not the case for command date.
...
d. systemd-timesyncd.service : a systemD service work works as a daemon with the NTP (Network Time Protocol) to synchronize the system time with remote NTP service. The corresponding configuration files can be found with man timesyncd.conf.
...
As shown in the picture, the following actions can happen regarding to the specific scenario or operations.
· The Linux get gets time from RTC (hardware) and store stores it as system time, and it is updated by interrupt from Oscillator.
...
· User can also use timedatectl to set the time. However, at the meantimemeanwhile, both the RTC and system time are updated.
· At system booting or periodically, the system time is synchronized with the NTP server on the network when this function is enabled by the user.
How to debug the problem about with RTC & time?
For convenience, some tips to locate the RTC-related problem will be described here.
In most cases, it appears as the time is not correct, showed with command date or timedatectl. then Then the following checks can be done to find some clue of the problem.
Have a check of the output of timedatectl, considering with the meaning of each item, find out whether it’s logical regarding
...
the context as you know (configuration, connection,.etc.).
...
If the item RTC time is n/a, one possibility is revpi-factory-reset has not
...
been done correctly.
Have a check of the kern.log with dmesg, if there are rtc-pcf2127 error logs existed like the following, it’s probably because the super cap is used out. Power on it, and let it be charged for a while (several hours) and reboot will be fine.
[ 10.528100] rtc-pcf2127 1-0051: pcf2127_set_datetime: err=-5
[ 10.528260] rtc-pcf2127 1-0051: pcf2127_get_datetime: read errorHave a check of the network connection to NTP server, whose URLs can be found in timesyncd.conf. Ping the NTP Server from the device to see whether the network connection is available.
...
Take a look
...
at the current time of the device, whether it’s 1970-xx-xx or 2016-xx-xx…. If it is in 2016, probably it is caused by discharge of RTC.
...
And it is quite not common in Linux now that the time goes back to 1970.
Check the output of executing hwclock -w or timedatectl status to trigger the reading of the RTC, if it
...
responds message containing “Invalid argument”, it
...
most likely caused by reading the RTC failed,
...
which can be caused by one of two reasons:
a. Something happened with the Oscillator in RTC, which you would see a warning log in kern.log as "oscillator stop detected, date/time is not reliable"
b. The time stored in RTC is not a valid time. e.g. earlier than 1970
Currently, no information about further determined
...
reasons for these problems, some analysis should be done according to use environment.
Check the NTP time synchronization information with the command systemctl status systemd-timesyncd
pi@RevPi1024:/etc $ systemctl status systemd-timesyncd
systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
`-disable-with-time-daemon.conf
Active: inactive (dead) since Fri 2019-11-29 14:57:44 CET; 3 days ago
Docs: man:systemd-timesyncd.service(8)
Process: 2329 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=0/SUCCESS)
Main PID: 2329 (code=exited, status=0/SUCCESS)
Status: "Idle."
Nov 03 18:17:38 RevPi1024 systemd[1]: Starting Network Time Synchronization...
Nov 03 18:17:38 RevPi1024 systemd-timesyncd[2329]: System clock time unset or jumped backwards, restoring from recorded timestamp: Fri 2019-11-29 14:51:23 CET
Nov 29 14:51:23 RevPi1024 systemd[1]: Started Network Time Synchronization.
Nov 29 14:53:15 RevPi1024 systemd-timesyncd[2329]: Synchronized to time server 217.91.44.17:123 (0.debian.pool.ntp.org).
Nov 29 14:57:43 RevPi1024 systemd[1]: Stopping Network Time Synchronization...
Nov 29 14:57:44 RevPi1024 systemd[1]: Stopped Network Time Synchronization.
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
References: