|Re: [chrony-users] High skew values|
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]
Thanks Bill for taking the time to reply.
On 2013-07-24 17:53, Bill Unruh wrote:
have the virtual server get its
This does sound like a good idea, but does chrony have a feature for doing this? Or any other software?
The host clock is available through hwclock, so I've added hwclock -us to cron for now, as that sort of does the job, but the system clock drifts 5-20s per minute so this solution "jumps" the clock a few seconds every minute, instead of slewing it nicely the way chrony does. Not sure if there is a better solution...
I would try to run chrony with one server
I gave this a try as well. It did make the "Can't synchronise: no majority" errors in /var/log/messages go away, but did not improve timekeeping in any way. So I'm not sure if that's a step forward...
I think that my lack of understanding of how this system works is limiting my ability to come up with useful solutions. I've read a lot of documentation over the past few days but still can't seem to understand what is actually happening.
Why might the skew be so high?
I "think" the answer to my original question is that the virtual machine does not get a consistent slice of CPU time the way a physical machine does. So timer interrupts do not happen at regular intervals, making it impossible for chrony to measure anything at a small scale. This was kind of explained in a small paragraph at the bottom of this document: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
The suggested solution for dealing with this is to add divider=10 to the kernel parameters and reboot. I tried this and it made no difference. So now I'm not sure if my understanding is correct.
several hours of accumulated drift over a day or so.
What's happening however, is that the system clock falls behind the real time clock or the hardware clock (ie, the host clock, which is well maintained) at a rate of 5-20s per minute (presumably depending on the relative load of the host and guest), resulting in several hours of drift per day.
What I don't understand is this: chrony logs the following in /var/log/messages:
chronyd: System clock wrong by 15.124741 seconds, adjustment startedIt does this (saying the clock is wrong by about 5-20s) even when the clock is wrong by hours.
In my reading on NTP, it seems like a simple enough system: The client asks several servers for the time, does some work to average the results, compensate for network latency and local latency (unreliable on a virtual machine), and slews the system clock accordingly. What I don't understand is, even in this ridiculously high skew situation, how can chrony let the system clock drift by hours? I can certainly understand a few seconds of inaccuracy given the inconsistency of the CPU, but hours?
Arnon Weinberg www.back2front.ca
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|