On 26 July 2016 at 19:33, Marcy Cortes <marcy.d.cor...@wellsfargo.com> wrote:
> Martin wrote: > > >Either the sysadmin or NTP should do this, otherwise the system clock > will be off by 26 seconds (soon 27 seconds as another leap second is > scheduled). > > This kind of implies that if I disable NTP on a server and reboot, it > should be 26 seconds or so off. > It's not. I'm seeing .003590 offset on one I just tried. > Unfortunately NTP does not work well inside a virtual machine. The algorithms are designed with network latency and eliminate those aspects. The latency in dispatching a virtual machine is rather different. I have seen an ntpd steered guest have serious mood swings, larger than the dispatch latency. And 3.5 ms is pretty good. If you need reasonable time in Linux, you might want to adjust clocks once during boot and not run ntpd after that. Go read the 100 pages on para-virtualized RTC on other platforms and notice there are still guests that drift away. Last time I looked, the HWCLOCK was broken for s390x. It is meant to deal with the cheap RTC chip to keep time over periods of power-off and primed the clock the wrong way (confusing ntpd and make the clock jump after a while). A z/OS system requires the hardware TOD to run TA1 and converts TOD clock values (current or historic) it uses a table with 26 ^w 27 TOD values where leap seconds were added. If you are close with z/OS your z/VM TOD runs TA1. Since z/VM does not have that table, your UTC (and local time for CP and CMS things) will be off by the 26 leap seconds unless you change it at IPL (which goes into the LPAR offset). The HMC has the current number of leap seconds defined to obtain the TA1 from NTP. You schedule the 27th leap seconds to happen just at the right time. When you're just 25 seconds off, someone forgot that update ;-) If you don't care about z/OS, you might keep the HMC-defined offset at 0 and run at UTC rather than TA1. When NTP injects the leap second, STP/ETR will work through the night and slowly adjust time again. A pragmatic approach could be to have a single virtual machine after z/VM IPL obtain UTC time (eg through my NTPDATE EXEC or a table with leap second moments) and issue a SET VTOD to correct the offset at IPL. The Linux guests could have the directory statement to say "I have what she has" and run all with the proper 26 seconds offset. Linux would see a TOD in UTC again. After that STP/ETR will steer the hardware TOD to stay on time. Unfortunately this does not handle the moment when the leap second is injected. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
