When I query the status of the NTP daemon with
ntpdc -c sysinfo I get the following output:
system peer: 0.0.0.0 system peer mode: unspec leap indicator: 11 stratum: 16 precision: -20 root distance: 0.00000 s root dispersion: 12.77106 s reference ID: [18.104.22.168] reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 system flags: auth monitor ntp kernel stats jitter: 0.000000 s stability: 0.000 ppm broadcastdelay: 0.000000 s authdelay: 0.000000 s
This indicates that the NTP sync failed. However the system time is accurate within 1 second precision. When I ran my system without network connection for the same period as I did now the system time would deviate ~10s.
This behavior suggests that the system has another way of syncing the time. I realized that there is also
systemd-timesyncd.service (with configuration file at
timedatectl status gives me the correct time:
Local time: Thu 2016-08-25 10:55:23 CEST Universal time: Thu 2016-08-25 08:55:23 UTC RTC time: Thu 2016-08-25 08:55:22 Time zone: Europe/Berlin (CEST, +0200) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2016-03-27 01:59:59 CET Sun 2016-03-27 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2016-10-30 02:59:59 CEST Sun 2016-10-30 02:00:00 CET
So my question is what is the difference between the two mechanisms? Is one of them deprecated? Can they be used in parallel? Which one should I trust when I want to query the NTP sync status?
(Note that I have a different system (in a different network) for which both methods indicate success and yield the correct time.)