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 <alan_altm...@us.ibm.com> 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
