Chrony or NTP?

[James H. Markowitz]

I have been using NTP all along, but my understanding is that NTP
has some problems both with its design and in the implementations under
all different flavors of Unix-like system. Is this correct? Should I move
to chrony?

[John McCue]

Post by James H. Markowitz
I have been using NTP all along, but my understanding is that NTP
has some problems both with its design and in the implementations under
all different flavors of Unix-like system. Is this correct? Should I move
to chrony?

If you are keeping it updated with patches
we have had, I see no reason to change.

[Rich]

Post by James H. Markowitz
I have been using NTP all along, but my understanding is that
NTP has some problems both with its design and in the implementations
under all different flavors of Unix-like system. Is this correct?
Should I move to chrony?

Can't comment on NTP, but I've been using Chrony all along and have
been happy with it.

Initially I started with Chrony because it supported intermittent
(dialup) connections. Once I had a full time net connection I simply
continued using Chrony.

[Roger]

On Sat, 8 Aug 2020 21:15:49 -0000 (UTC), "James H. Markowitz"

Post by James H. Markowitz
I have been using NTP all along, but my understanding is that NTP
has some problems both with its design and in the implementations under
all different flavors of Unix-like system. Is this correct? Should I move
to chrony?

I think it's probably more correct to say that the designers of
chrony decided that they didn't like how certain aspects of ntp
worked and did things differently. Both work but there may be
situations where one or the other may be more appropriate.

Should you move to chrony? No, not immediately. Read about ntp
and chrony. Monitor how well ntp works in your situation. Then
install chrony and monitor it. Compare the two and ask yourself
whether either is better, worse, or just different.

[Mike Small]

Post by James H. Markowitz
I have been using NTP all along, but my understanding is that NTP
has some problems both with its design and in the implementations under
all different flavors of Unix-like system. Is this correct? Should I move
to chrony?

What cases are you concerned about? A couple of years ago ntpd had a few
security vulnerabilities clustered around the same time, but its record
overall hasn't been bad.

Myself, I can only think of one case I care about, the make case. Say
I run for awhile with no network and my clock gets ahead somehow. I
build a program, then I reboot and quickly edit a file and run make
again. If ntpd had stepped the clock backwards the change could be
ignored since the object file looks newer than the source file.

I've been running with -x and -g options. The -x option will prevent it
stepping the clock unless it's more than 600 s off. -g will let it
step but only one time on start up. Without the -g ntpd will panic
with a log message if the clock is off by more than 1000 s.

I'm debating using an ntp.conf tinker option to instead always slew
and nothing else. If the clock gets way off I'll notice and can
adjust manually. That would protect me from ntpd stepping the clock
backwards and confusing a build. But is that the only way of going
backwards? Could a reboot give me a system time in the past too,
without ntpd's intervention?

Now I'm not so concerned, since I only have laptops with properly
functioning real time clocks. Every time I check the offset with
ntpq it is very good. But it might be nice if there was a setting
that would allow ntpd to step the clock forward no matter how great
the offset but never let it step backward. So far I haven't found
such an option.