On 10/12/06, Ihno Krumreich <[EMAIL PROTECTED]> wrote:

> IIRC the NTP mechanism was to review adjusting the change of the drift
> every 2 seconds or so. Even though this is very little work, it does
> make VM think the guest is busy and keeps it in queue. Asking the snmp
> agent every minute for some MIBs (when the guest did real work) is an
> order of maginute less annoying for VM.

No. Thats not true. When starting NTP looks quite often (dont remember how 
often).
The more the reference clock and the local clock are in sync the less NTP
checks the state. This goes down to a check every few hours.
So after a while NTP should not be visible at all from a VM point of view.

I'm not used to that response on my posts, so let me clarify.
The model behind the ntp support in the kernel is a based on 4
different parameters:
* constant base offset
* frequency difference (skew)
* aging of the oscillator (drift)
* variation in the skew (jitter)

The correction needed to steer the system clock to keep up with true
time is used to determine these parameters. The offset is done by
yanking the clock initially. The skew is done by a small extra that is
added with each jiffy count. The drift is implemented by a change of
the skew that is made every 2 seconds. The jitter is not corrected but
recognized by the algorithms to avoid too drastic changes to the
drift.

My experience is limited, but all zSeries clocks that I have measured
were a weeny bit too slow (some skew of ~ 1 ppm) but stable (no
measureable drift). So provided you correct the initial offset
(Operator Mickey Mouse clock) with an ntpd -q  the worst that happens
is that the (daily) ntpd -q will 'yank' the clock forward a little
(say 100 ms per day or so). This is good enough for a lot of
applications.

The variation introduced by the dispatch queue in CP is way larger
than what you want to correct. This dispatch delay will be depending
on the system overall load. These long term variations as observed by
ntpd running in a Linux virtual machine do not match the jitter model
very well. The net effect is that running ntpd against some set of
reference clocks makes your clock less stable than the zSeries clock.

Rob
--
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to