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.
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).
When running with a plain old local TOD clock, the situation is much the
same as on other hardware. The sysadmin must configure the system to
know how to correctly extract a UTC clock value from the hardware clock
at boot. There are no leap seconds to apply, and to keep the clock in
sync after boot, it is best to configure NTP.
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.
Aye, at least for an STP managed hardware clock.
Note that generally, Linux does not assume that any hardware clock runs
at UTC. There are various situations where it makes sense to have a
hardware clock run in local time and have the hwclock utility apply a
suitable adjustment to obtain the correct UTC clock value to set the
system clock.
So there is no fundamental problem here, as far as I can see.
All that is needed is to obtain access to whatever info is needed to
obtain a correct UTC clock value from the raw hardware TOD clock value.
Given my current understanding that the STP clock hardware can actually
provide the OS with correct and continually updated information about
the leap second offset to be applied to the hardware TOD clock to obtain
the current UTC clock value, it seems to make sense to implement the
necessary logic in the Linux kernel hardware clock driver so it will
automatically apply the correct offset to the TOD clock as per the
current admin settings (i.e. either the actual leap second offset
provided by the STP hardware to run an STP synced clock, or the current
internal system clock offset to run an NTP managed or manually set clock).
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/
