Hmmm... When configuring STP and the HMC to retrieve time from a GPS based NTP server appliance, I am betting that the GPS time source also already has the leap seconds applied. In that case - Should we be setting the HMC leap second value for the STP network to 0 ?
On Tue, Jul 26, 2016 at 4:37 AM, WF Konynenberg <[email protected]> wrote: > Hi Martin, > > A more definite source of information. Good. :-) > > > On 07/26/2016 09:21 AM, Martin Schwidefsky wrote: > >> On Tue, 26 Jul 2016 01:30:03 -0400 >> Alan Altmark <[email protected]> wrote: >> >> >> Linux on z does not alter the TOD clock after it's booted. NTP affects >>> only the offset from the TOD that the kernel maintains. Any app that >>> wants to know the time must ask the kernel. It can't just issue STCK(E). >>> >> This is important enough to reiterate: STCK(E) will not give you the >> correct >> system time if you are using NTP to drift the time. Use gettimeofday() to >> retrieve the time, this call is optimized with a function in the VDSO. >> The VDSO knows about the offset between the TOD clock and the system time >> and does the necessary calculations. It is reasonable fast as no system >> call is required. >> > > Well duh. Applications on Linux should generally not go directly to the > hardware for this kind of info, but rather should use defined standard > operating system interfaces. > > Even if you aren't using NTP to keep the time in sync, when the hardware > TOD is not kept in UTC (as it appears to be the case with STP), and the > sysadmin has correctly set the system time to UTC, the time you get from > STCK(E) would be off by some 26 seconds from the correct UTC system time. > > > >> In an LPAR, Linux will sync the LPAR TOD to the CPC TOD when it boots. >>> After that it depends on STP, and it really depends on having the proper >>> number of leap seconds configured in the CPC and in Linux. >>> >> Only if STP is enabled. The default is off, in this case Linux just uses >> the >> current TOD clock to initialize the system time. >> > > This is getting a bit confusing to me. > Do I understand correctly that when STP is enabled, Linux uses the > hardware TOD clock directly as its system clock, adjusting it on the fly > as needed as per any local system clock adjustments that have been made? > And that otherwise it simply initializes the internal system clock from > the TOD clock at startup and then runs an independent software system > clock, in the classic way? > > > >> We really need CP to virtualize STP (when real STP is being used e.g. with >>> NTP). That would allow Linux to always have the correct time without >>> running its own NTP client. >>> >> It would certainly improve things but for at least one aspect you still >> need NTP: to inject leap seconds. >> > > You shouldn't really need NTP for that. > The doc I just read about STP seemed to suggest that the leap second > info is entered into the hardware console by the admin and then obtained > by some means by z/OS to apply the appropriate UTC adjustment to the TOD > clock, before applying the local time adjustment. > If Linux could access this same info somehow, it could apply the same > adjustment to its UTC system clock. > > >> The problem today is that VM will not generate a sync check when the >>> difference between NTP and the TOD becomes large enough that it cannot be >>> steered out in a short period of time, such as when the external time >>> source is reconnected or when a leap second is added. >>> >> STP does not generate a sync check for leap seconds, they are not >> included in >> the TOD clock. The programming notes in the PoP about the Time-of-Day >> Clock >> you will find this: >> >> "In converting to or from the current date or time, the programming >> support >> must take into account that leap seconds have been inserted or deleted >> because of time-correction standards. When the TOD clock has been set >> correctly to a time within the standard epoch, the sum of the >> accumulated >> leap seconds must be subtracted from the clock time to determine UTC >> time." >> > > Hmm, so how is the leap second info kept up to date for z/OS? > > When you have a hardware clock that is accurately synced to an external > UTC based clock source, it seems wasteful to continually run NTP on > every guest just to apply a known and mostly constant leap second > correction. I would much prefer a more efficient (hardware clock > specific) mechanism to reliably distribute and apply this information > for any Linux guests. > > >> -- >> 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/ >> >> > > Willy > > > ---------------------------------------------------------------------- > 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/ > -- Jay Brenneman ---------------------------------------------------------------------- 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/
