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

Unruh unruh-spam at physics.ubc.ca
Thu Jan 24 05:55:54 UTC 2008


mayer at ntp.isc.org (Danny Mayer) writes:

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

As I said it is not easy, particularly because the clock is used as a
sheduler. If the only problem were the gettimeofday and adjtimex (to use
the Linux expression) then you could simply replace them by having them
interface with a clock simulator. HOwever there are the schedulers (timers) and
timeout functions which are harder to make work in a simulator. 








More information about the questions mailing list