On Wed, 27 Jul 2016 10:28:04 +0200 Rob van der Heij <[email protected]> wrote:
> On 26 July 2016 at 19:33, Marcy Cortes <[email protected]> > 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). Are you referring to the RTC clock interface of the kernel? If so then yes, that never worked for s390. If you look into drivers/rtc/Kconfig you'll find this: menuconfig RTC_CLASS bool "Real Time Clock" default n depends on !S390 && !UML select RTC_LIB help Generic RTC class support. If you say yes here, you will be allowed to plug one or more RTCs to your system. You will probably want to enable one or more of the interfaces below. > 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 I do a "#cp query time" on my z/VM guests I get something like this: 00: CP QUERY TIME 00: TIME IS 14:01:14 CST WEDNESDAY 07/27/16 00: CONNECT= 99:59:59 VIRTCPU= 007:13.79 TOTCPU= 007:35.53 The interesting part is "CST", which stands for coordinated server time. And this does not include leap seconds. That implies that your local time for CP and CMS is not in UTC, no? > 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. Why should STP adjust anything after NTP injected a leap second?!? The TOD clock does not include leap seconds, there is nothing to adjust. The NTP injected leap second will only show up in the system time offset that is added to the TOD clock. > 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. Well, STP will report the TOD time stamp when a leap second is due. How to do the leap second clock drift is up to the OS. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
