time to sync vs ptp?

matthew...@gmail.com

unread,

May 30, 2013, 2:41:27 PM5/30/13

to

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.

After doing this, the clock's offset was *increasing* after an hour. Offset is measured by "ntpdate -q peer".

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.

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?

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?

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.

Thanks,
Matt

Rob

unread,

May 30, 2013, 3:21:15 PM5/30/13

to

matthew...@gmail.com <matthew...@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.
>
> After doing this, the clock's offset was *increasing* after an hour. Offset is measured by "ntpdate -q peer".

This is a wellknown problem.
When you do a couple of ntpd shutdown/restarts e.g. because you
a experimenting with different server configurations, the combination
of ntpd and the kernel goes haywire and it will actually steer the time
the wrong way.

Just wait a day or so, and it will have solved itself.

David Lord

unread,

May 30, 2013, 5:22:07 PM5/30/13

to

matthew...@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.
>
> After doing this, the clock's offset was *increasing* after an
hour. Offset is measured by "ntpdate -q peer".
>
> 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.
>

You might as well keep using the date command and forget about
ntpd. You are fighting ntpd and have little chance of winning.

After a reboot my pcs usually are within 1 ms within 30 minutes,
and that's about the best they will do in my non temperature
controlled location. Periods better than 300 usec do happen but
they depend on the weather and the pcs being otherwise idle. Ntpd
relies on establishing a drift file, /var/db/ntp/ntpd.drift on
my systems. The drift file can take many hours to be established
and many days if you keep experimenting and making changes.

If you need to experiment then try a more recent version, I'm
using 4.2.6p5 on NetBSD (I've tried some 4.2.7 versions but had
no success).

David

unruh

unread,

May 30, 2013, 6:35:52 PM5/30/13

to

On 2013-05-30, matthew...@gmail.com <matthew...@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.

matthew...@gmail.com

unread,

May 31, 2013, 9:42:45 AM5/31/13

to

Would it be possible to provide a link or point me to some reference material where I can read more about this issue?

Thanks!

matthew...@gmail.com

unread,

May 31, 2013, 10:19:43 AM5/31/13

to

On Thursday, May 30, 2013 5:35:52 PM UTC-5, unruh wrote:
> 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)

OK. But at some point, when the drift file is established, it has a memory of sorts, right?

> 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.

I didn't mean to suggest that NTP should be changed; I apologize if it came out that way. I was asking if there were existing tools or configuration options that might help me make better use of this tool. I anticipated responses along the lines of "check out this document which explains the behavior you are seeing" or "take a look at config option xyz which might help".

Thanks again,
Matt

David Woolley

unread,

May 31, 2013, 10:33:45 AM5/31/13

to

matthew...@gmail.com wrote:

>
> OK. But at some point, when the drift file is established, it has a memory of sorts, right?

Not in the sense that unruh means. If you ignore the minimum delay
filter, ntpd uses an IIR filter with only z^0 and z^1 terms, so it only
remembers the state from one accepted sample back. Linear regression
based system actively use values from several back samples in each
iteration.

The drift file provides a checkpoint of part of the state, but is only
used after an outage.

You can consider the minimum delay filter as using z^0 to z^7, but it
ends up only selecting one of these, even though it uses all of them to
make the decision.

unruh

unread,

May 31, 2013, 11:31:39 AM5/31/13

to

See the end of www.theory.physics.ubc.ca/chrony/chrony.html where I
discuss chrony vs ntpd

The idea is simply. If the rate is out, but the offset is small, then it
will take a while for that rate error to manifest itself in the offset (
which is the only thing used to drive ntp).

Rob

unread,

May 31, 2013, 11:49:39 AM5/31/13

to

I think the issue is never acknowledged by the author. He believes
his system is proven to be stable. It is only in practice that we
see this happen, it cannot happen in theory.

unruh

unread,

May 31, 2013, 3:11:59 PM5/31/13

to

No. He will acknowlege that it can happen in theory (I gave a quick
handwaving explanation). But he is interested in the long term
stability, not the short term behaviour of the system. that kind of
behaviour will occur in any feedback system like ntpd uses.

Assme that initially the offset is zero, but the rate is wrong by 10PPM.
The system will assume initially that everything is fine. It is only
when the rate error causes an offset to develop, that ntpd will begin to
alter the rate of the clock to correct that offset. It only does this
adjustment slowly so it will be a while ( while the offset has wandered
even further from zero) for the rate error to have been eliminated., By
then the offset is large, so the system will overcorrect to rate to
bring the rate back down to zero. If you handle the time factors and the
correction magnitude, the resulting system will be almost critially
damped so that there is not an oscillation. And if it is close to
critical damping then it also does not take too long. to reach that
state.

It is not unexpected. With memory ( ie knowing what the past offsets
were and the rate corrections were) one can much more raplidly approach
the stable euqilibrium. That is what chrony does. Tests that both I and
Lichvar have done indicate that chrony not only does it much more rapidly approach
stability, but also creates a smaller average offset spread than does
ntpd in many situations (the spread of offsets are between a factor of 2
to 20 times better than with ntpd). Certainly more tests, under a wider variety
of conditions are needed.

Brian Utterback

unread,

May 31, 2013, 3:27:52 PM5/31/13

to

There was a bug in the start up of NTP that caused it to set the
frequency before setting the first offset. This meant that the kernel
PLL treated the first offset correction as a "drift" in time since the
time the frequency was set (seconds before) which introduced a sudden
jerk to the loop, which, depending on the circumstances, might send it
careening off the mark.

I reported this as bug 1044. I believe that the fix for bug 1981 may
have fixed this, but I have not verified it yet.

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions