[email protected] 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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
