On Thu, Oct 12, 2006 at 07:50:21PM +0200, Rob van der Heij wrote: > 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.
If I have offended you, I apologize for that. > 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. > I totally agree with you. > 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. > As I wrote in the second part of my mail I see no need to run ntp on a zSeries to have a stable time there. The only scenario I see is, if multiple machines (and not only zSeries) needs to have a stable time. The question on top was whether ntp keeps z/VM busy. And I think this is not the case. Regards Ihno "Never trust a computer you can lift." -- Ihno Krumreich [EMAIL PROTECTED] SUSE LINUX Products GmbH Projectmanager S390 & zSeries Maxfeldstr. 5 +49-911-74053-439 D-90409 Nürnberg http://www.suse.de ---------------------------------------------------------------------- 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
