[EMAIL PROTECTED] (Danny Mayer) writes: >Harlan Stenn wrote: >>>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
