On Thursday, 07/21/2016 at 08:28 GMT, Christian Ehrhardt <[email protected]> wrote: > If you run "ntpq -pn" you get a list of servers as configured and an offset > of your system too them. > Now since your Linux guests are ticking at the same rate by the HW design, > the offset to the same NTP peers should stay the same. > > If these offsets differ on your systems, something on that system has set > time to be that offset. > > Also, if you continue debugging this I'd recommend trying to stay away from > high level things like "date" as there are so many levels in between which > could skew things. > Write a minimal program calling STCKE should be way more reliable. > And if you find the difference is always zero on STCKE level, but once you > move to more abstracted functions like clock_gettimeofday / gettimeofday > you can start debugging down that route.
The CP QUERY VTOD command will tell you the guest's offset from the system clock (the "SIE epoch"). If it is non-zero, the guest has changed its clock via an instruction or the CP SET VTOD command. No STCKE program needed. But other than at boot time, I don't think Linux sets the clock, but simply keeps track of the difference between the timand the TOD clock, applying that delta whenever an application asks for the time via a kernel interface. The delta is discovered by Linux's support for STP and/or by NTP. Since z/VM doesn't virtualize STP, the guest must rely on NTP. All of this is necessary because a properly configured CPC runs with the z/Architecture standard epoch, meaning that you have configured the leap seconds, and TOD = UTC + LEAP (LEAP = 26, as of this writing). The traditional NOW = TOD calculation results in NOW = UTC + 26. But their non-z brethren are calculating NOW = UTC. The 26-second delta is unacceptable, so you have to run NTP. If you are NOT running on the standard epoch, then you have leap seconds set to zero. That means STP will set the TOD to UTC and keep it there. When the next leap second occurs (this Dec. 31), STP will think that it's running fast and increment the clock more slowly, bring the TOD back into sync with UTC. That takes about 7 hours. But you're out of sync by 1 second at the start of that 7 hours. To avoid the leap second problem, you still need NTP on the guest. Read more about STP, z/VM, and Leap Seconds at http://www.vm.ibm.com/devpages/altmarka/vmleap.html. Now, why might the guests report different times? I suspect because their calculations of the round-trip delay will be different and heavily influenced by steal time. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- 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/
