[ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
unruh at wormhole.physics.ubc.ca
Mon Mar 14 06:41:59 UTC 2011
On 2011-03-14, Ralph <ralph at depth.net> wrote:
> Maybe what I'm misunderstanding is the 'how' of that measurement? And I correct
> that the assumption in all this is that the system clock ticks are consistent?
> And that is the root of the problem in getting things to work properly on a VM?
> In reading the NTP spec it sounded to me like the formula involved taking the transmission from the client (org), receipt at server (rec), server transmit (xmt), and client receipt (dst). The problem lying with the fact that if the
> clock ticks on the client aren't consistent, then the client realistically
> doesn't know that the distance between org and rec is even comparable to the
> distance between xmt and dst, correct? And further the client can't tell during
> which segment of time the variation in time occurred, right?
The problem is not the round trip measurement ( although that can be a
minor problem). The problem is that the rate of the vm clock is not
consistant, and thus ntp, which adjusts the clock by adjusting the rate
( and strongly assumes that that rate changes slowly if it changes)
cannot adjust if the clock rate keeps changing by large amounts.
> I've been doing a little playing around with hwclock and adjtimex to see what the
> various clocks are really doing. What it looks like is that the hardware clock
> is reporting time accurately (over time at least) even though the system clock
Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on
any of the system timers. However it typically has a rate that is many
PPM out and that rate cannot be adjusted. This makes it completely
unsuitable for the clock adjustment that ntp uses. Also setting that
clock is tough and it is not very accurate ( only delivers time to the
second-- and on modern system even that can be somewhat inaccurate since
the rtc interrupt has been screwed up in modern versions of Linux. Also
setting the clock only occurs .5 sec after the adjustment is actually
made.). The rtc makes for a lousy clock.
> isn't. I'm assuming that this is because under the covers the VM is having the
> hardware clock report time in sync with the clocking on the host.
Nope. The HW clock is a clock which is completely separate from the
> So maybe if we could have a mode where ntpd uses the hardware clock to measure the round trip and instead of the system clock? Or just uses the hardare clock
Impossible. The HWclock has a precision of only 1 second. And if your
round trip times are many seconds long, you are in a situation where VM
are the least of your worries ( eg on a spaceship)
> as the reference? And then adjusts the system clock to be closer to accurate?
> In this way if you have a host system that is properly adjusted so that the
> hardware clock of the VM is reporting fairly accurrately, then you ought to be
> able to get ntpd to adjust the system clock to properly reflect the time.
> I know this is similar to what one can do with adjtimex, but it would be nice
> if there was a way to have this done properly without having to work adjtimex
> manually and determine 'by hand' what the right values are.
> So now I'm probably going to get told to go find the adjtimex newsgroup... but since this is time related, I hope that maybe you will continue to humor me.
More information about the questions