[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

Danny Mayer mayer at ntp.isc.org
Wed Jan 23 13:10:07 UTC 2008

Harlan Stenn wrote:
>>>> In article <4796CB87.7070400 at ntp.isc.org>, mayer at ntp.isc.org (Danny Mayer) writes:
> Danny> Harlan Stenn wrote:
> Unruh> Unfortunately I cannot run both ntp and chrony on the same system at
> Unruh> the same time.
>>>  Bill,
>>> Exactly why can you not run ntpd and chrony on the same system at the
>>> same time?
> Danny> Harlan, really. You *cannot* have two different
> Danny> mechanisms/applications to discipline the clock at the same time. I
> Danny> invite you to try. You have access to my code so you can test this
> Danny> easily.
> You are, as is so often the case, missing my point.  It is possible to run
> ntpd in a way that it does not discipline the clock.

In which case you are not able to compare the two algorithms since the 
clock is the central part of the testing and algorithm.

>  I am curious about
> your last sentence though - what is special about your code that would allow
> this to be tested?

It includes the noall option. You can then run two instances on the same 
box and have one discipline the clock and the other not. Feel free to 
have both of them try. The results will be hilarious.

>>> I want the ability to run multiple instances of ntpd where at most 1
>>> instance of ntpd is actually controlling the clock, specifically to make
>>> it easy to (more quickly) analyze the performance/behavior of different
>>> configurations of ntpd.  I understand that the boat is rocking while this
>>> is going on, but I suspect this capability would be a useful one in at
>>> least some cases.
> Danny> I don't see the benefit of doing this with two separate
> Danny> instances. It's easier and simpler to just add the other servers into
> Danny> the one instance and specify noselect.
> Again you are missing my point.  Allowing this would let us, for example,
> see how two different versions of ntpd would discipline the clock.  It would
> allow us to see how ntpd might discipline the clock compared to chrony.
> I understand and "get" that by not actually disciplining the clock we are
> removing an important part of the feedback loop, and I do not know if that
> will fatally affect these sort of experiments or not.

No you cannot do that. The clock is the central part of the algorithm. 
You *cannot* have two different applications discipline the clock 
without disasterous results.

Put it this way: chrony decides that it needs to adjust the clock 
frequency and amount by amount dX and X. ntpd decides to change it by dY 
and Y. When chrony next looks at the clock it decides that the change it 
made wasn't good enough and makes changes by an even bigger amount and 
delta. and so on and so forth.

> And as Bill said, it would be Swell if there was a way to do this using, eg,
> virtual machines so that we could test them that way.  Better yet, it would
> be nice to have a simulator framework where we could run these tests faster
> than in real-time.

Virtual machines buys you the same problem as above. Even on a virtual 
machine there's only one clock. You can have only one application 
discipline that clock never mind how many virtual machines are running. 
Don't be fooled by the technology.

There are no simulators that I've ever seen that can run tests faster 
than real-time. They are always many orders of magnitude slower, even 
with hardware assist.


More information about the questions mailing list