ntpd, chrony [was: Re: [plug] Backimg up entire drive]

[William Kenworthy]

On Mon, 2004-01-05 at 20:09, Cameron Patrick wrote:
> On Mon, Jan 05, 2004 at 07:55:57PM +0800, William Kenworthy wrote:
> 
> | I was having probs with ntp and decided to shift to chrony.  Whilst
> | initially happy, I have gone back to ntp.
> | 
> | Chrony requires rtc as a module or compiled in
> 
> !? Not AFAIK.  It can take advantage of it if present, though.  From my
> /etc/chrony/chrony.conf:
> 
>From the chrony-1.1.19 docs:
"So far, the support for real-time clocks is limited - their code is
even more system-specific than the rest of the software. You can only
use the real time clock facilities (the rtcfile directive and the -s
command line option to chronyd) if the following three conditions apply:

     1. You are running Linux version 2.2.x or 2.4.x (for any value of
        x), or v2.0.x with x>=32. 
     2. You have compiled the kernel with extended real-time clock
        support (i.e. the /dev/rtc device is capable of doing useful
        things). 
     3. You don't have other applications that need to make use of
        /dev/rtc at all. "

me!: vmware is one such application.

> | Time regulation was poor compared to ntp on a dialup with a high usage
> | (i.e., teenagers ...)
> 
> !? I'm using it on a couple of machines with ADSL lines and have seen no
> problems with it keeping time in sync to the ntp server.
> 
I got rid of it before I went adsl.  Problem occurred when dialup pipe
was maxed out for a long time (downloading iso's for instance) - ntp
seems better able to handle this

> | Didnt like stop/start operation (would silently die - often!)
> 
> Hmm, haven't noticed that, even when I was back on dialup.
> 
> | gentoo has had a tick adjust in the kernel that ntp can handle, but
> | chrony demands it be only set to 100. 
> 
> Ahh.  That may be a real problem.  Since I'm a Debian person and have
> conservative tastes in kernels, I haven't been bitten by this one
> either. ;-)
> 
> | overall I find ntp just works
> 
> (except when it thinks the clock is too far out and gives up entirely,
> or randomly decides to stop talking to the ntp server for some reason or
> other)
Check out the tinker command for the ntp config file, and I think there
is a command line arg to overide the default behaviour.  Note that some
chrony commands like trimrtc and makestep are manual (and makestep can
cause a step in time keeping just like ntp does when its slew threshold
is exceeded), and need to be manually executed to get chrony back in
sync, whereas ntp does it automaticly.  In particular, a few months back
some gnome and kde apps would hog the kernel timeslice (e.g., when
checking laptop battery charge) causing wholesale timekeeping drift. 
Chrony sync'd marginially better than ntp under these conditions, but
would often need manual resyncing to catchup, while ntp could be
configured to do it automaticly (but specs had to be very "loose").

With good conditions, either will be fine, but on a bad link I would try
both to see which behaves best.  Also some of the earlier ntp/xntp
implementations did not handle dialups well (whats debian using?) at all
(giving some of the conditions you describe), but later ones are far
better.

BillK