[ntp:questions] time to sync vs ptp?

unruh unruh at invalid.ca
Thu May 30 22:35:52 UTC 2013

On 2013-05-30, matthew.garman at gmail.com <matthew.garman at gmail.com> wrote:
> I have a server running NTP 4.2.2 (as part of the RedHat 5.7 release).  Last night I changed it's /etc/ntp.conf file, specifically the "server xyz" line to point to a new NTP server.

Why in the world would you use such an old version of ntp and an old
version of the distro. Many many security issues have arisen and been
patched since then.
> After doing this, the clock's offset was *increasing* after an hour.  Offset is measured by "ntpdate -q peer".

Yes, the offset increasing after an hour is certainly possible and even
likely if the drift rate is wrong. That is how ntpd words.

> From what I've gathered about NTP, it attempts to adjust clocks "gently" and "slowly".  What I'm doing now, and I'm sure this will make some cringe, is to run "ntpdate -u -b peer" in a loop, sleeping two seconds between runs.  I understand this is the opposite of slowly and gently.

Yes, and this still does not address the problem of the drift rate. ntpd
has to run a while to figure out what the right drift rate is.
Unfortunately it does so by a Markovian (no memory) feedback, which is
slow and suffers from exactly the kind of behaviour you see. If you want
something faster ( and more accurate) run chrony instead. (It keeps a
memory and thus lcan figure out where it wants to be in terms of offset
and drift far faster than can ntpd)

> But is there a way to somehow combine the behavior of both?  Be a little more aggressive like ntpdate, but retain some of the "politeness" of the daemon?

As I said, ntpdate does not adjust the drift rate. 
And ntpd IS more aggressive if the offset exceeds 128ms. It will then
step the clock (a la ntpdate). Note that ntpdate simply steps the clock,
which means it canstep backwards which can mess up your filesystem. 

> For what it's worth, I've recently been playing with the open-source PTPv2 daemon.  It appears to "beat the system clock into submission" rather quickly---I see syncs occurring typically in a matter of minutes.  Is there a way to make NTP act more like PTP with regards to getting clocks sync'ed quickly?

David Mills has a very strongly held philosophy about how ntpd should
behave, and he is not about to change that. If you like ptpv2 better,
use it. 

> I know I'm using very figurative/non-specific terminology here... but I'm trying to wade through all the NTP documentation, but it quickly gets over my head, and I'm not sure what's applicable and what's not.  Hopefully this list can help me get a better handle on this stuff.

You are not going to change anyone's mind with "I am ignorant, and have
no idea what I am talking about, but could you not change ntpd in the
following way." You are far better off finding a program that behaves
the way you want, and use that. 

More information about the questions mailing list