[ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Mon Mar 14 11:45:09 UTC 2011


Rob wrote:
> unruh<unruh at wormhole.physics.ubc.ca>  wrote:
>> 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.
>
> Why do you keep asserting that, while you clearly don't know what you
> are talking about?
>
> You keep assuming that the time in the client is measured by number of
> CPU cycles, which is of course hogwash.
>
> The time in the client can be determined from a number of sources, and
> in Linux you can even select which source the kernel should use for
> timekeeping.  The sources selectable depend on the kernel version.
>
> Each of those sources is virtualized, to a more or less good degree.
> But your idea that the CPU is scheduled away from the client and then
> those sources stop dead and lose time, is completely wrong.

It is in fact so wrong that a recent VMware report quoted here stated 
that with current VMware products you would get _better_ time sync on a 
client OS by running ntpd on the client, than by running ntpd on the 
host and using VMware's option to always time sync the client to the host.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list