On Wed, May 21, 2008 at 8:53 PM, Richard Troth <[EMAIL PROTECTED]> wrote:
> The spiffy thing about time on System z is that the clock is incredibly > stable. (Ticks at the right rate, though may be off by several minutes. > It's always off by the same "several minutes" to great precision.) If we > could get the underlying clock set really accurately, I suspect we'd still > want to run NTP on most guests for validation and consistency. Sir Santa is very right about the stable System z clock. I measured this on old gear a few years ago, but have no reason to assume IBM made it worse. http://rvdheij.nl/Presentations/2005-L76.pdf So yes, the concern is where the hardware is very constant but different from all the remote systems (that often use NTP). This may bother some installations and applications. With Linux on z/VM, I think it is in general *not* a good idea to try to correct this with NTP. One of the problems is that CPU virtualisation. This is observed by Linux as small time variations. However, the nature of these variations is different from the type of clock defects that the NTP logic tries to compensate. So you end up with larger variations in an attempt to steer the clock. And there's a few more issues with the tools it that actually make it a lot worse, like stepping the clock backwards. I find it hard to believe that systems would have extreme time requirements but yet tolerate yanking the clock back.... The best solution is to synchronize your hardware TOD (at POR) with a reliable time source (i.e. not the $5 Mickey Mouse watch of the operator). In the old days we had the 9037-2 that would do that, and also steer the TOD carefully based on a weekly dial-up to some time service. But STP makes that a lot easier. So the best approach is to make z/VM run on time and let all virtual machines run at exact that same clock, so not running NTP themselves. If you let STP "steer" the hardware TOD then your systems continue to run on time. The acceleration of the TOD to catch up is so small that I can not imagine anything with Linux on z/VM notice it. It avoids the need for NTP completely, and provides a much more stable clock. If you don't have the gear to do this, then I would prefer a single virtual machine with to start up first and use NTP to obtain the right time and then uses SET VTOD according to that. The Linux virtual machines starting after that would ask CP to have "the same time as that one" and no need to run NTP either. And yes, running ntpdate now and then works, as long as your system can afford the clock being yanked (fortunately, all clocks I have seen run a weeny bit too slow, so ntpdate will step it forward, not back). Rob -- Rob van der Heij Velocity Software GmbH http://velocitysoftware.com/
