Unruh, I'm sure you know that an ntpd simulator is included in the NTP software distribution. It handles multiple simultaneous servers using the same algorithms as in the working daemon. We use it to test the daemon response to all kinds of possible but unlikely scenarios, all at warp speed.
So, why ae we having this discussion? Whip up a worthy opponent for chrony and we can watch a glorious battle of the simulators. For your first battle, I have rawstats for a bumpy backdoor path to Malaysia. I am astonished at your comments about poll interval and reading the clock, which are totally independent of each other. The ntpd daemon has configurable disconnects for the feedback loop and for individual servers. I assume chrony has similar features, as you wouldn't be able to make the claims you do without them. Reading your claims literally, chrony would have to slew the clock considerably greater than the 500 PPM provided by the standard Unix adjtime() system call. Please explain how it does that. Dave Unruh wrote: > [EMAIL PROTECTED] (Danny Mayer) writes: > > >>Unruh wrote: >> >>>[EMAIL PROTECTED] (Danny Mayer) writes: >>> >>> >>>>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. >>> >>>Not if the virtual machines have a virtual clock-- Ie a little program >>>which intercepts all the clock routines and return the output of a little >>>program simulating a clock. Now intercepting the various adjtimex calls is >>>not that hard ( just rewrite the adjtimex and gettimeofday routine and and >>>overload it for >>>your program) but chrony and ntp also use the clock as a scheduler, and >>>that is a lot more difficult to simulate and catch. >>> > > >>As a fellow physicist I would expect you to understand this better. It's >>a basic principal in quantum mechanics: the observers influences the >>observed results. In this case, it's not enough since you are directly >>and deliberately affecting the clock itself and there really can only > > > NO you do not understant. The "clocks" I am talking about are NOT hardware > related clocks, they are just subroutines which return what is supposed to > be a time when queried, and which change their algorithm for generating > those numbers when disciplined by the program. > > The really big problem is that the system goes into wait states, and you > would also have to wake it up appropriately. For example, the polling > interval is done by the clock. Now there is absolutely no reason why a poll > which is supposed to be running at poll 10 could not return immediately > with the clock set to tell it that 1024 sec had passed. However getting > this right would require a really big rewrite of the NTP or chrony program. > > > >>and deliberately affecting the clock itself and there really can only >>be one clock. Multiple clocks lead to chaotic events. All "virtual > > > Of course there can be many clocks. After all each computer I have has one > so if I have 10 computers I have 10 clocks. NOw of course you are refering > to a single computer with a single bit of hardware. But the virtual clocks > I am talking about are not hardware related at all. They are just > subroutines which spit out an number when queried. > > > >>>>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. >>> >>>We are not asking for a machine simulator but a clock simulator and that >>>can run thousands of times faster than the real clock. You can run it at >>>any speed you want. And you can have a separate simualted clock with its >>>own theory of operation on each virtual machine. > > >>I've run many different simulators including hardware ones and I can >>assure you nothing runs slower than a simulator. Like I said there is >>only one real clock in a virtual machine, there just appears to be one >>per virtual machine. > > > A simulator of a clock can run far far faster than a clock. After all I can > output the numbers from 1 to 10000 far faster than 10000 sec. That is how > weather forcasting works. The simulation of the weather is run much faster > than the real weather. Otherwise the forcast is a bit useless. > > > > >>Danny _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions