Quoting Simon Hobson (linux@???):

> From memory, ntp does have problems with clocks that are a long way
> out of sync - or has that been fixed ?

The NTP protocol _inherently_ has problems with system clocks that are a
long way out of sync -- in the sense that, yes, you can easily force an
NTP client (_any_ NTP client) to programmatically wrench local time,
correcting a huge time skew to force it into compliance with a remote
time source, but is that really a good idea? Especially automatically?

If local time suddenly lurches forward or backward a great distance,
already running processes may get very distressed or fall over, log
files will become very peculiar, etc. For those and similar reasons,
big yanks of time skew correction, albeit perfectly feasible with
standard tools, tends not to be done automatically (on a theory that
maybe you ought to fix your system clock problem rather than papering it
over with NTP).

I note the following options to /usr/bin/ntpd (from the reference
ntp.org implementation) to perform such indelicate yanking where and if
desired:

       -g     Normally,  ntpd  exits with a message to the system log if the
              offset exceeds  the  panic  threshold,  which  is  1000  s  by
              default.   This  option allows the time to be set to any value
              without restriction; however, this can happen only  once.   If
              the  threshold  is  exceeded after that, ntpd will exit with a
              message to the system log.  This option can be used  with  the
              -q and -x options.

       -q     Exit  the  ntpd  just  after  the first time the clock is set.
              This behavior mimics that of the ntpdate program, which is  to
              be  retired.   The  -g  and  -x  options can be used with this
              option.  Note: The kernel time  discipline  is  disabled  with
              this option.

       -x     Normally,  the  time  is slewed if the offset is less than the
              step threshold, which is 128 ms by  default,  and  stepped  if
              above the threshold.  This option sets the threshold to 600 s,
              which is well within the accuracy window to set the clock man-
              ually.   Note:  Since the slew rate of typical Unix kernels is
              limited to 0.5 ms/s, each second  of  adjustment  requires  an
              amortization  interval of 2000 s.  Thus, an adjustment as much
              as 600 s will take almost 14 days to  complete.   This  option
              can be used with the -g and -q options.  Note: The kernel time
              discipline is disabled with this option.

Regulating time using NTP is one of those things that is normally
very simple and Just Works[tm], except in lots of fiddly corner
cases when it isn't. The simple, Just Works[tm] default configuration
works almost everywhere, all the time. The complex non-default options
and tweaks are for all of those corner cases and unusual needs.


Note: There's certainly nothing wrong with chrony, nor with OpenNTPd,
nor ntimed-client, but none of them is a magic bullet that makes
everything right and simple.

The only client to point and laugh at is systemd-timesyncd.

timesyncd does no clock discipline, can't assess the quality of the
remote time source, doesn't trick jitter and delay over time, and has
poor accuracy. It also stupidly does disk I/O every single time it
adjusts the system clock, and doesn't even bother to try adjusting time
gently, never applying the delta gradually. It's the dumb, crude
hillbilly of NTP clients; any of the other four is serviceable,
respectable, capable, and flexible. The systemd team would have been
much better off incorporating ntimed-client, which is under 5k lines of
code and implements a full proper NTP client -- competently.

But no. They had to do their own, and do a much worse job at gratuitous
cost in time and effort.


I can't yet recommend Poul-Henning Kamp's ntimed-client as a simple, tiny
NTP client solution for Devuan/Debian desktop users, but only because
it's not available packaged, and because it is technically still beta.
So one of the other three is (for now) a more natural go-to choice. If
interested in this (very) obscure topic, his blog entries about progress
on the project make interesting reading: http://phk.freebsd.dk/time/

When finished, it will become a subproject of the reference ntp.org
implementation (not a competing, separate ntp client).


For those who want to set the time hillybilly-style, i.e., Just Do It
and Yes, My System Clock Is Possibly Way Off, and use the reference
ntp.org software:

# ntpd -gqc /dev/null server1.name.net server2.name.org server3.name.com

Above will always work, provided system clock is within about 68 years
of current time.

Do _not_ use ntpdate any more. It doesn't work well.
https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

-- 
Cheers,                         Grammarian's bar joke #22:  The past, present, 
Rick Moen                       and future walked into a bar.  It was tense.
rick@???                                                           
McQ! (4x80)