On Tue, 26 Jul 2016 17:29:24 +0200 WF Konynenberg <[email protected]> wrote:
> Hi Martin, > > On 07/26/2016 04:12 PM, Martin Schwidefsky wrote: > > On Tue, 26 Jul 2016 10:37:33 +0200 > > WF Konynenberg <[email protected]> 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). > > Indeed. Where "the sysadmin" could simply translate to "a suitable > hwclock equivalent tool that understands how to apply the leap second > adjustment to the value returned by the hardware clock", being run in > the RC scripts roughly where on other systems hwclock would be run. > Though in this case, if the leap second info is actually available from > the hardware in a defined way, you might as well just stick that tiny > bit of logic in the linux kernel code that reads the hw clock at boot to > initialize the system clock. > > > > >>>> 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? > > The Linux kernel does this as IPL time, it does know better at this early > > stage. Later when user space is powered up you can use e.g. ntpdate to > > set a more reasonable system time. > > Given what you write below about STP providing this info and even a nice > interrupt when the value changes, I'ld say that the Linux kernel > *should* know better and be able to initialize the system clock > correctly from the hardware clock from the get go. Like this? ;-) commit 936cc855ffe808b428cf75116fe031af9f12237e Author: Martin Schwidefsky <[email protected]> Date: Tue May 31 12:47:03 2016 +0200 s390/time: add leap seconds to initial system time The PTFF instruction can be used to retrieve information about UTC including the current number of leap seconds. Use this value to convert the coordinated server time value of the TOD clock to a proper UTC timestamp to initialize the system time. Without this correction the system time will be off by the number of leap seonds until it has been corrected via NTP. Signed-off-by: Martin Schwidefsky <[email protected]> > >> 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. > > STP reports the current number of leap seconds. It even gives you a nice > > interrupt to inform you that a change in the number of leap seconds > > is due. But what do you do with this information? You can not just add > > the leap second, if you have NTP running as well you end up with duplicates. > > And you do not want to insert the leap second twice.. > > That ought to be reasonably simple: > > When running with an STP synchronized hardware TOD clock, by default you > do exactly what the documentation says z/OS does in that case: > Take the STCK(E) output, apply the leap second offset provided by the > STP hardware, and use the result as the reference UTC value. > When the Linux kernel is using the TOD as its system clock and merely > applies a delta to report the actual system clock value, then it should > probably adjust the offset whenever the leap second offset changes. > When the Linux kernel is using its own internal software system clock, a > similar delta should be applied to the system clock upon a leap second > change. > The resulting behaviour of the Linux system clock will be comparable to > its behaviour when it is managed by NTP. > > When running with an STP synchronized hardware TOD clock, but the > sysadmin choses to use NTP anyway, then the STP leap second adjustment > should be disabled after the initial system clock initialisation (it is > needed for the first clock initialization to ensure that the system > clock is initially running at UTC, thus avoiding the need for NTP to > apply a clock jump). .. but the sysadmin chooses to use NTP anyway.. in this small sentence lies the problem. How do you know? From the kernel perspective the interface is the adjtimex system call. Any process with CAP_SYS_TIME can do the leap second injection. Today this might be process "ntpd", tomorrow this might be systemd and some different tool. There is no way to be sure that there is some user space tool that takes care of the leap seconds for you. -- 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/
