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

Danny Mayer mayer at ntp.isc.org
Thu Jan 24 02:46:40 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.  I am curious about
> your last sentence though - what is special about your code that would allow
> this to be tested?
> 
>>> 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.
> 
> 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.

You do realize that there are timers built into the code so in order to 
run faster you'd need to figure out how to change the timers to work 
that way?

Danny



More information about the questions mailing list