As usual, the group comes through again; many thanks to all who have posted, it helped a lot.
Yes, the problem the client is concerned about is implementing a security scheme across LPARs (and across CECs as well) that requires accurate time be kept. Not microsecond accurate, but more accurate that what the Operator can provide at VM IPL time from his watch. To recap: 1) VM (actually, CP) does not participate in the new SNT, once CP has it's hardware TOD clock set from either the HMC or the Operator, that's it, no changes to the h/w TOD clock. 2) It is feasible for Linux to run a network time protocol server as a guest of VM, so Linux images can keep their clocks in sync with an ETR. 3) Linux guests should *not* be enabled to get the CP timezone change external interrupt, they do that themselves. Does that pretty much sum up the consensus of the group? Many thanks again and have a good one. DJ ----- Original Message Follows ----- From: Alan Altmark <[EMAIL PROTECTED]> To: [email protected] Subject: Re: z/VM, NTP, and the z/10. Date: Wed, 21 May 2008 19:08:05 -0400 > On Wednesday, 05/21/2008 at 02:43 EDT, dave > <[EMAIL PROTECTED]> wrote: > > My question is: what > > happens if z/VM is running on one of those LPARs and > > PR/SM, under the covers, keeps updating z/VM's hardware > TOD clock? > > As CP perceives time, nothing happens. The clock keeps on > ticking. But to the outside observer the ticks will > occur faster or slower, depending on whether the LPAR is > ahead or behind. No sudden clock movements and no > anti-time is introduced (time will not flow backwards). > Think of it like slowly turning a screwdriver that > adjusts the clock oscillator frequency. > > The drift is so small that it takes a long time (human > scale) for the drift to reach the point at which > "steering" is not possible. Only when the machine has no > external time reference (e.g. NTP) will the clock drift > that far. Only when the h/w is reconnected will STP tell > the LPAR (if the opsys has asked to be told) that the > time shift is too severe to steer back on course in a > reasonable amount of time and that a Quantum Leap has > happened. > > Alan Altmark > z/VM Development > IBM Endicott
