Hi Alan,
On 07/26/2016 07:30 AM, Alan Altmark 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).
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.
So is this a confirmation that the TOD is not maintaining UTC and
expects the OS to apply the leap second correction? If so, is the info
about the leap second correction to be applied available from the
hardware somehow, or is the OS expected to maintain this information
separately? The STP doc I read seemed to suggest that the leap seconds
info is maintained via the hardware console, which would mean the info
is meant to be somehow passed from the hardware to the OS. Having to
keep a separate leap second administration in each guest OS would be
rather inconvenient.
The Linux system clock is supposed to be kept at UTC, not at TAI (with
or without some fixed offset), so if the hardware TOD clock is not at
UTC, then linux should somehow make sure to apply the appropriate
correction when setting its system clock from the TOD clock at boot. If
it doesn't, then the Linux system clock of a guest will be at a
predictable offset of some 26 seconds from UTC at boot, and the only
sensible way to fix that would be to let NTP jump the clock at startup
to the correct time. This, of course would negate the purpose of having
the TOD synced to an external clock reference by STP.
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.
I'm not sure I understand this. What is needed is that there is a known
standard mechanism to extract the correct current UTC time from the
hardware TOD clock. There should not be any need to adjust the TOD
clock, just to know what leap second adjustment to apply when the TOD
clock itself is not actually keeping UTC time.
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.
If I understand correctly, the "problem" here is merely that if NTP is
not configured to jump the clock on startup but instead is requested to
carefully "slew" the clock into sync, and when the system clock is some
26 seconds out of sync at startup, the clock adjustment can take quite
some time, and all this time the Linux guest has a system clock that is
significantly out of sync with UTC.
The quick fix would be to configure your Linux NTP to jump the clock at
startup. The real fix would be to make sure that the Linux kernel
somehow correctly sets the system clock to UTC from the TOD, instead of
knowingly setting it incorrectly to a known offset from UTC.
This is no different from when on a PC one were to misconfigure their
linux hardware clock settings and, e.g. incorrectly initialize the Linux
UTC system clock to local time, causing the initial system clock to be
some known number of hours off. Misconfiguring your Linux system to not
match your hardware setup is just generally not a good idea.
Btw, I don't know whether Linux on Z has some mod to just run its system
clock off the TOD, but generally Linux only initializes its internal
system clock from the TOD at boot, and from then on runs its clock
independently in software. If you have a reliable TOD hardware clock
that you would like to sync your system clock to, you probably need to
run some software (similar to NTP, but using the local clock reference)
to tune the system clock and keep it in sync. The NTP server software
includes some drivers for various external hardware radio clocks to sync
to to effectively run an NTP "Stratum 0" clock. Maybe a z/Architecture
TOD clock driver could be added to that, or alternatively a simple
daemon to run without NTP to continually tune & adjust the system clock
from the TOD (which is a much simpler task than a general NTP
implementation) using the same underlying kernel mechanism that NTP uses
Alan Altmark
Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
IBM Endicott
----------------------------------------------------------------------
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/
----------------------------------------------------------------------
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/
