Hi, as Michael already mentioned the guests only have a offset they can store in the SIEBK. The clock of all your guests are ticking at the same pace, so you have no traditional different drifting due to different clocks on one system z box. If you have a difference between your Linux Guests that should be from your Linux actually setting time (and by that actually their offset). Given the permissions and access one could surely check the offsets of both guests, but that can be quite hard :-)
For all other checks the issue will almost always be, that you would have to send a command to both at the same time which is impossible - so you can never compare most of the output if they just report "date" or such. But NTP which you already have running can help you to find if those two systems are apart. 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. Kind Regards, Christian Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Thu, Jul 21, 2016 at 1:18 AM, Marcy Cortes <marcy.d.cor...@wellsfargo.com > wrote: > I used a rexx exec to send commands to the console (secuser) that looked > like this: > > /**/ > address command "CP SEND ZLA226 date +'%d/%m/%Y %H:%M:%S:%6N'" > address command "CP SEND ZLA247 date +'%d/%m/%Y %H:%M:%S:%6N'" > > I would expect ZLA247's to be a bit later, but sometimes it shows earlier. > > 18:04:34 20/07/2016 18:04:34:735597 > 18:04:34 20/07/2016 18:04:34:737365 > > 18:06:42 20/07/2016 18:06:42:317457 > 18:06:42 20/07/2016 18:06:42:325410 > > 18:08:50 20/07/2016 18:08:50:473232 > 18:08:50 20/07/2016 18:08:50:467567 > > 18:13:51 20/07/2016 18:13:51:055624 > 18:13:51 20/07/2016 18:13:51:037563 > > Hmm. > > -----Original Message----- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Michael Harding > Sent: Wednesday, July 20, 2016 2:47 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: [LINUX-390] Back to the future? > > In the guests' VMDBKs, in the SIEBK is stored the offset from the hardware > clock that gets loaded when the guest is run. I don't recall the offset in > the block. Unless that's different they should both be seeing the same CPU > clock. > > -- > Mike Harding > z/VM System Support > /sp > > > Linux on 390 Port <LINUX-390@VM.MARIST.EDU> wrote on 07/20/2016 01:42:05 > PM: > > > From: Marcy Cortes <marcy.d.cor...@wellsfargo.com> > > To: LINUX-390@VM.MARIST.EDU > > Date: 07/20/2016 01:42 PM > > Subject: Back to the future? > > Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> > > > > So we have some servers that pass timestamps around to see how long > > they have to do something before throwing in the towel. > > > > They've recently put in some logging to debug some errors and have > > found some cases of going back in time. > > > > TmsSent 2016-07-20 07:40:07.000034 | TrapRx 2016-07-20 07:40:06.000944 > > > > So back in time by nearly a second (.99909). > > > > These 2 servers are on the same VM system. Both run NTP. > > We know things get really out of whack without NTP. We had a bug > > where it didn't start and things got really confused. > > > > Could NTP be misbehaving? It was just patched. How can I prove > > that the clocks on the 2 servers have a different time so that I can > > ascertain if it is NTP or something else. > > > > > > > > Marcy > > > > > > > > ---------------------------------------------------------------------- > > 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/ > > > > ---------------------------------------------------------------------- > 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/ > > ---------------------------------------------------------------------- > 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/ > ---------------------------------------------------------------------- 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/
