karl@??? wrote:

>> npt only synchronizes only on machine starts.
>
> That is wrong, I guess you are thinking about initial sync.
>
> You can do initial syncronisation with e.g. ntpdate, but ntpd can do
> that also, but can take more time before it decides to jump the clock
> if it differ too much.
>
> Then ntpd, while running, will at some regular interval,
> syncronize the clock. Run ntpq -p to see the polling interval.
>
> The ntp.conf file installed with devuan is perfectly fine for
> a newbies always-connected system. If your box only has intermittent
> connection to the internet, ntpd might not be what you need.
> You might then be better served by chrony or something else.

For clarification ...

From memory, ntp does have problems with clocks that are a long way out of sync - or has that been fixed ? I suspect that was part of the reason for running ntpdate on startup. As I'm normally working with systems that a) are always on, and b) have working hardware clocks with batteries, this hasn't been a problem for me so I haven't followed developments.

By default, ntpd will start with a polling interval of 64 seconds, and over time will increase this up to 1024s (17 minutes). If you specify an iburst value for a peer in the config file, then it will poll several times in a short space of time during startup - shortening it's sync time.

As above, ntpq -p will list the currently configured peers and their status. After a while, one will be listed with "*" before it's entry - this is peer it currently considers the primary and which it will sync the clock. Others marked with "+" are candidate to be the primary.

My configured servers are :
server ntp.plus.net
server ntp2b.mcc.ac.uk
server ntp2c.mcc.ac.uk
server ntp.cis.strath.ac.uk
server ntp.ox.ac.uk

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-cdns01.plus.net 195.66.241.3     2 u  396 1024  377   30.702   -0.750   0.322
*frome.mc.man.ac 193.62.22.66     2 u  452 1024  377   39.684    0.277   0.231
+utserv.mcc.ac.u 193.62.22.66     2 u  317 1024  377   39.488   -0.010   0.382
+ntp0.cis.strath 193.62.22.74     2 u  630 1024  377   42.858    0.002   0.672
 ntp0.ox.ac.uk   .STEP.          16 u    - 1024    0    0.000    0.000   0.000

Taking the second line from this, it says my local daemon is synced to frome.mc.man.ac[.uk] (ntp2b.mcc.ac.uk is an alias to frome) which in turn is synced to 193.62.22.66. Frome is a stratum 2 server, it was last polled 452 seconds ago, the polling interval is now 1024s and it responded for each of the last 8 polls (377 in octal is 1111 1111, if any poll fails, then the reach column will indicate this with a 0 for each poll that failed). The round trip time for the poll was a little under 40 ms, the local clock is offset by .27ms, and the jitter (variation in round trip time and time offset between polls) is 0.23ms.
I'm assuming ntpd has selected this peer because it has the lowest jitter. If there were peers with different stratums, then ntpd will favour the higher stratum ones - stratum is basically how many hops from a "high quality" time source (such as the atomic clocks run by the likes of NPL).

ntp0.ox.ac.uk has never responded (must get round to removing that some time), and I think cdns01.plus.net (ntp.plus.net) has been discounted as a candidate for primary peer because it's clock disagrees with the rest.

On another system I see :
$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*patsy.thehobson 130.88.203.13    3 u  423 1024  377    1.079   -0.125   0.237

showing that the ntp daemon running on patsy is stratum 3 because it's synced to a stratum 2 peer.


As said, just installed the ntp package should give you a working time sync - using four servers from the ntp.org pool. If your clock is not syncing, then the first debugging tool is ntpq -p and see what is going on.


As an aside, you may find this interesting to see how some miscreants are (or were, it was written 5 years ago) using the Debian pool to find devices to port scan.
http://netpatterns.blogspot.com/2016/01/the-rising-sophistication-of-network.html

Simon