On Tue, 26 Jul 2016 10:37:33 +0200 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. 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). > > > >> 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. > > > >> 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. 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.. > > > >> 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. Trouble is the *hardware* clock is not in UTC. -- 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/
