Strangely accurate RTC time on Debian

[Logan]

Hi friends.
One of my PC's RTC only drift 0.3 seconds over 15 days, and it even correct itself sometimes (so it's not always faster or slower).
It's so strange because it's using a similar configuration compare to another PC, which drift ~10 seconds per day...
There's no ntpd installed, how can I check if there's any software syncing time for me, or is this RTC just happens to be so accurate?
Thank you for reading.

[RoGeorge]

In Ubuntu (which is a customised Debian) the time synchronization is on by default.  Try this from a terminal:
timedatectl status

[Nominal Animal]

Instead of ntpd, systemd uses systemd.timesyncd service.

Even though you don't have ntpd or anything similarly named running, you do have an ntpd client-only systemd.timesyncd service running.

[Logan]

Thank you both.
Here's some CLI results:

~$ timedatectl status
               Local time: Thu 2024-05-16 22:32:31 UTC
           Universal time: Thu 2024-05-16 22:32:31 UTC
                 RTC time: Thu 2024-05-16 22:32:31
                Time zone: UTC (UTC, +0000)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

~$ timedatectl timesync-status
Failed to query server: The name org.freedesktop.timesync1 was not provided by any .service files

~$ timedatectl show-timesync
Failed to parse bus message: No route to host

~$ timedatectl show
Timezone=UTC
LocalRTC=no
CanNTP=no
NTP=no
NTPSynchronized=no
TimeUSec=Thu 2024-05-16 22:32:45 UTC
RTCTimeUSec=Thu 2024-05-16 22:32:45 UTC

~$ systemctl status systemd.timesyncd
Unit systemd.timesyncd.service could not be found.

Still seems not synced...

[SiliconWizard]

Yep. systemd-based distributions rarely use ntpd, although you can use it instead of systemd.timesyncd if you prerfer. That's what I had set up myself, but it turned out that ntpd was much slower to update time than timesyncd for some reason, so I eventually resorted to timesyncd.

Also to answer the OP, not all RTCs on motherboards are born equal. 10 seconds per day of RTC drift is about 115 ppm, which is about average (not good) for a *basic* crystal-based oscillator, and proof in itself that it's not network-synced.

But 0.3 s of drift over 15 days would be 0.23 ppm, which, while not completely impossible with a good TCXO, is completely unlikely to be what you get with any consumer PC RTC, so it's evidently network-synced.

[Logan]

Thank you, but as CLI shown above, systemd.timesyncd is also not the case.
I did heavy clean after initial installation, so many components are striped off.

[SiliconWizard]

Thank you, but as CLI shown above, systemd.timesyncd is also not the case.
I did heavy clean after initial installation, so many components are striped off.

Try with a dash instead:

systemctl status systemd-timesyncd

[Logan]

You mean this?

~$ dash
$ systemctl status systemd.timesyncd
Unit systemd.timesyncd.service could not be found.

Looks the same.
I also tried sudo, same result.

[SiliconWizard]

No, read (or copy-paste) again the command line I posted. A dash instead of a dot in systemd-timesyncd

[Logan]

Ahhhh...

~$ systemctl status systemd-timesyncd
Unit systemd-timesyncd.service could not be found.

Same result with sudo.

[amyk]

Also to answer the OP, not all RTCs on motherboards are born equal. 10 seconds per day of RTC drift is about 115 ppm, which is about average (not good) for a *basic* crystal-based oscillator, and proof in itself that it's not network-synced.

But 0.3 s of drift over 15 days would be 0.23 ppm, which, while not completely impossible with a good TCXO, is completely unlikely to be what you get with any consumer PC RTC, so it's evidently network-synced.

I think PC RTCs were much more accurate in the days when they were not expected to be network-synced. I have some old PCs which drift at most a minute per year.

[RoGeorge]

~$ timedatectl status
               Local time: Thu 2024-05-16 22:32:31 UTC
           Universal time: Thu 2024-05-16 22:32:31 UTC
                 RTC time: Thu 2024-05-16 22:32:31
                Time zone: UTC (UTC, +0000)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

Looks like it's not synced.  You've been lucky to have a very good RTC. 
The ultimate test would be to physically disconnect the LAN cable/wireless, and see if it keeps the same accuracy. 

Question is, how much its frequency will change with time, with battery voltage, and with temperature.

My Ubuntu machine reports this:

Code: [Select]

~$ timedatectl status
               Local time: Fri 2024-05-17 09:24:36 EEST
           Universal time: Fri 2024-05-17 06:24:36 UTC
                 RTC time: Fri 2024-05-17 06:24:36
                Time zone: Europe/Bucharest (EEST, +0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
~$