Re: Back to the future?

[Marcy Cortes]

Can you include where to find those CPC STP leap seconds definitions. I read 
the write up earlier today and thoroughly confused my HW guy when asking him 
about our config.



Marcy

-Original Message-
From: Alan Altmark [alan_altm...@us.ibm.com]
Sent: Wednesday, July 27, 2016 08:23 PM Central Standard Time
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Back to the future?


Working on a more comprehensive post, along with an update to my 
http://www.vm.ibm.com/devpages/altmarka/vmleap.html to provide more of the big 
picture and a better explanation of what is/isn't possible.Regards,  Alan



   Marcy Cortes --- Re: [LINUX-390] Back to the future? ---
From:"Marcy Cortes" 
To:LINUX-390@VM.MARIST.EDUDate:Wed, Jul 27, 2016 
5:19 PMSubject:Re: [LINUX-390] Back to the future?

It's a tough one.  Even if you took all the info in this thread and managed 
to understand it all, I don't think it would be complete.   And I'm still 
looking for that second.Hoping the app guy comes back and tells me to never 
mind, it's his bug :)-Original Message-From: Linux on 390 Port 
[mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark PostSent: Wednesday, July 
27, 2016 12:50 PMTo: LINUX-390@VM.MARIST.EDUSubject: Re: [LINUX-390] Back to 
the future?>>> On 7/27/2016 at 03:06 PM, Michael MacIsaac  
wrote: > I nominate you to write it :))Note the word "cooperative" in my 
suggestion.  No one person is going to be able to do this justice.Mark 
Post--For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visithttp://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 
lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visithttp://www.marist.edu/htbin/wlvindex?LINUX-390--For
 more information on Linux on System z, visithttp://wiki.linuxvm.org/

--
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/

Re: Back to the future?

[Alan Altmark]

Working on a more comprehensive post, along with an update to my 
http://www.vm.ibm.com/devpages/altmarka/vmleap.html to provide more of the big 
picture and a better explanation of what is/isn't possible.Regards,  Alan



   Marcy Cortes --- Re: [LINUX-390] Back to the future? --- 
From:"Marcy Cortes" 
To:LINUX-390@VM.MARIST.EDUDate:Wed, Jul 27, 2016 
5:19 PMSubject:Re: [LINUX-390] Back to the future?
  
It's a tough one.  Even if you took all the info in this thread and managed 
to understand it all, I don't think it would be complete.   And I'm still 
looking for that second.Hoping the app guy comes back and tells me to never 
mind, it's his bug :)-Original Message-From: Linux on 390 Port 
[mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark PostSent: Wednesday, July 
27, 2016 12:50 PMTo: LINUX-390@VM.MARIST.EDUSubject: Re: [LINUX-390] Back to 
the future?>>> On 7/27/2016 at 03:06 PM, Michael MacIsaac  
wrote: > I nominate you to write it :))Note the word "cooperative" in my 
suggestion.  No one person is going to be able to do this justice.Mark 
Post--For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visithttp://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 
lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visithttp://www.marist.edu/htbin/wlvindex?LINUX-390--For
 more information on Linux on System z, visithttp://wiki.linuxvm.org/

--
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/

Re: Back to the future?

[Marcy Cortes]

It's a tough one.  Even if you took all the info in this thread and managed to 
understand it all, I don't think it would be complete.   

And I'm still looking for that second.
Hoping the app guy comes back and tells me to never mind, it's his bug :)


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Wednesday, July 27, 2016 12:50 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Back to the future?

>>> On 7/27/2016 at 03:06 PM, Michael MacIsaac  wrote: 
> I nominate you to write it :))

Note the word "cooperative" in my suggestion.  No one person is going to be 
able to do this justice.


Mark Post

--
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/

--
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/

Re: Back to the future?

[Mark Post]

>>> On 7/27/2016 at 03:06 PM, Michael MacIsaac  wrote: 
> I nominate you to write it :))

Note the word "cooperative" in my suggestion.  No one person is going to be 
able to do this justice.


Mark Post

--
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/

Re: Back to the future?

[Michael MacIsaac]

Mark,

Great idea!

I nominate you to write it :))

-Mike M

On Wed, Jul 27, 2016 at 2:50 PM, Mark Post  wrote:

> All,
>
> What I'm reading in all this is a serious lack of current and complete
> understanding across a wide range of hardware/firmware/kernel
> software/userspace software.
>
> I know quite some time ago, Rob van der Heij gave a presentation at SHARE
> about the topic.  It seems to me a cooperative effort to get that updated
> and posted somewhere, or a "white paper" type document that covers all this
> would be of considerable value to everyone.
>
>
> Mark Post
>
> --
> 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/
>

--
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/

Re: Back to the future?

[Mark Post]

All,

What I'm reading in all this is a serious lack of current and complete 
understanding across a wide range of hardware/firmware/kernel 
software/userspace software.

I know quite some time ago, Rob van der Heij gave a presentation at SHARE about 
the topic.  It seems to me a cooperative effort to get that updated and posted 
somewhere, or a "white paper" type document that covers all this would be of 
considerable value to everyone.


Mark Post

--
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/

Re: Back to the future?

[Ronald van der Laan]

Martin and Rob,

Op woensdag 27 juli 2016 heeft Rob van der Heij  het
volgende geschreven:

> On 27 July 2016 at 14:09, Martin Schwidefsky  > wrote:
>
>
> > Are you referring to the RTC clock interface of the kernel? If so then
> yes,
> > that never worked for s390. If you look into drivers/rtc/Kconfig you'll
> > find this:
> >
> > No, I meant the HWCLOCK setting in the startup which tried to read the
> RTC
> check and then primed the ntp offset with a bogus value.
> I believe ntpd uses two files with previous offset and drift. It might be
> interesting if you could manufacture those with the proper offset and prime
> the ntp offset and do away with the steering.
>
>
> > If I do a "#cp query time" on my z/VM guests I get something like this:
> >
> > 00: CP QUERY TIME
> > 00: TIME IS 14:01:14 CST WEDNESDAY 07/27/16
> > 00: CONNECT= 99:59:59 VIRTCPU= 007:13.79 TOTCPU= 007:35.53
> >
> > The interesting part is "CST", which stands for coordinated server time.
> > And this does not include leap seconds. That implies that your local time
> > for CP and CMS is not in UTC, no?
> >
> >
> No, I believe "CST" is the time zone name. This might be abusing the
> abbreviation for "Central Standard Time" as something like "Central Europe
> Summer Time".  If you do a Q TIMEZONE you may find that it's been set to so
> many hours off GMT (or you see it's linked to STP).
>
>
Almost certainly CeST for Böblingen.
For some reason I do not really understand, the timezone fields in CP are 4
chars long, only at a few places, the maximum timezone name is limited to 3.
Strange if you consider that most official timezone names are 3 or 4 long.
A similar odd restriction is in the maximum timezone offset, local time in
Kiribati is hard to configure in VM, East 14:00 and officially
called LINT.  Though there are probably not that many z's installed there.


> The logic in z/VM does not have the leap seconds table built-in, so if you
> want the right local time then someone must have compensated for the leap
> seconds (either by hardware clock UTC or LPAR offset to UTC-TA1).
>
> Rob
>
> --
> 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/
>


-- 
Ronald van der Laan

--
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/

SHARE Atlanta - Request for Chairs

[John Crossno]

 Hi Everyone!

Last chance to sign up ahead of time to volunteer to chair one or more
sessions. Please let me know ASAP. There are only 7 sessions left to pick
from. Surely some of you plan to attend these sessions, right? Time to help
out! Please email me directly with your choices. Thanks!

Session ID Session Title Day Date and Time Speakers
19366 Introduction to Virtualization Mon 2016-08-01, 10:00:00 Romney White
(Speaker)
19391 Advanced Systems Management of LinuxONE and Linux on z Systems using
IBM Wave for z/VM Tue 2016-08-02, 15:15:00 Eduardo C. Oliveira, IBM, Wave,
for, z/VM, Tiger, Team, Lead (Speaker)
19146 SUSE Linux Technical Update Wed 2016-08-03, 16:30:00 Mark Post
(Speaker)
19321 Installing and Configuring IBM MobileFirst Platform on Linux for z
Systems Thu 2016-08-04, 10:00:00 Matthew T. Cousens (Speaker)
19984 IBM Wave for z/VM Setup, Use Cases, and Field Experiences Thu 2016-08-04,
13:45:00 Richard G. Young (Speaker)
19436 RACF Advanced Configuration/Auditing Thu 2016-08-04, 15:15:00 Bruce
Hayden (Speaker)
19445 Dialogue and Requirements Discussion for IBM z Systems Virtualization
and Linux Thu 2016-08-04, 16:30:00 Steffen Thoss (Speaker), George Madl
(Speaker)

--
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/

Re: Back to the future?

[Marcy Cortes]

Under z/VM.

I used the ntpdate command that Christian posted and also eyeballed them.

zlnx168 is recently rebooted and is not running ntp.  zlnx169 is

zlnx168:~ # ntpdate -qv zlnx169
27 Jul 09:21:21 ntpdate[4014]: ntpdate 4.2.8p8@1.3265-o Mon Jun  6 08:19:21 UTC 
2016 (1)
server 10.93.15.169, stratum 5, offset 0.003511, delay 0.02582
27 Jul 09:21:27 ntpdate[4014]: adjust time server 10.93.15.169 offset 0.003511 
sec
zlnx168:~ # uptime
 09:21am  up   0:03,  2 users,  load average: 0.13, 0.16, 0.07
zlnx168:~ # ps -ef | grep ntp
root  4019  3975  0 09:21 pts/000:00:00 grep ntp



-Original Message-
From: Martin Schwidefsky [mailto:schwidef...@de.ibm.com] 
Sent: Wednesday, July 27, 2016 1:17 AM
To: Linux on 390 Port
Cc: Cortes, Marcy D.
Subject: Re: Back to the future?

On Tue, 26 Jul 2016 17:33:31 +
Marcy Cortes  wrote:

> Martin 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).
> 
> This kind of implies that if I disable NTP on a server and reboot, it should 
> be 26 seconds or so off.
> It's not.   I'm seeing .003590 offset on one I just tried.

LPAR or z/VM? I just tried as well and I do get the 26 second offset for both 
LPAR and z/VM.
How did you get the timestamps you are comparing?

-- 
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/

Re: Back to the future?

[Rob van der Heij]

On 27 July 2016 at 14:09, Martin Schwidefsky  wrote:


> Are you referring to the RTC clock interface of the kernel? If so then yes,
> that never worked for s390. If you look into drivers/rtc/Kconfig you'll
> find this:
>
> No, I meant the HWCLOCK setting in the startup which tried to read the RTC
check and then primed the ntp offset with a bogus value.
I believe ntpd uses two files with previous offset and drift. It might be
interesting if you could manufacture those with the proper offset and prime
the ntp offset and do away with the steering.


> If I do a "#cp query time" on my z/VM guests I get something like this:
>
> 00: CP QUERY TIME
> 00: TIME IS 14:01:14 CST WEDNESDAY 07/27/16
> 00: CONNECT= 99:59:59 VIRTCPU= 007:13.79 TOTCPU= 007:35.53
>
> The interesting part is "CST", which stands for coordinated server time.
> And this does not include leap seconds. That implies that your local time
> for CP and CMS is not in UTC, no?
>
>
No, I believe "CST" is the time zone name. This might be abusing the
abbreviation for "Central Standard Time" as something like "Central Europe
Summer Time".  If you do a Q TIMEZONE you may find that it's been set to so
many hours off GMT (or you see it's linked to STP).

The logic in z/VM does not have the leap seconds table built-in, so if you
want the right local time then someone must have compensated for the leap
seconds (either by hardware clock UTC or LPAR offset to UTC-TA1).

Rob

--
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/

Re: Back to the future?

[Martin Schwidefsky]

On Wed, 27 Jul 2016 10:28:04 +0200
Rob van der Heij  wrote:

> On 26 July 2016 at 19:33, Marcy Cortes 
> wrote:
>
> > Martin 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).
> >
> > This kind of implies that if I disable NTP on a server and reboot, it
> > should be 26 seconds or so off.
> > It's not.   I'm seeing .003590 offset on one I just tried.
> >
>
> Unfortunately NTP does not work well inside a virtual machine. The
> algorithms are designed with network latency and eliminate those aspects.
> The latency in dispatching a virtual machine is rather different. I have
> seen an ntpd steered guest have serious mood swings, larger than the
> dispatch latency. And 3.5 ms is pretty good. If you need reasonable time in
> Linux, you might want to adjust clocks once during boot and not run ntpd
> after that. Go read the 100 pages on para-virtualized RTC on other
> platforms and notice there are still guests that drift away.
>
> Last time I looked, the HWCLOCK was broken for s390x. It is meant to deal
> with the cheap RTC chip to keep time over periods of power-off and primed
> the clock the wrong way (confusing ntpd and make the clock jump after a
> while).

Are you referring to the RTC clock interface of the kernel? If so then yes,
that never worked for s390. If you look into drivers/rtc/Kconfig you'll
find this:

menuconfig RTC_CLASS
bool "Real Time Clock"
default n
depends on !S390 && !UML
select RTC_LIB
help
  Generic RTC class support. If you say yes here, you will
  be allowed to plug one or more RTCs to your system. You will
  probably want to enable one or more of the interfaces below.

> A z/OS system requires the hardware TOD to run TA1 and converts TOD clock
> values (current or historic) it uses a table with 26 ^w 27 TOD values where
> leap seconds were added. If you are close with z/OS your z/VM TOD runs TA1.
> Since z/VM does not have that table, your UTC (and local time for CP and
> CMS things) will be off by the 26 leap seconds unless you change it at IPL
> (which goes into the LPAR offset). The HMC has the current number of leap
> seconds defined to obtain the TA1 from NTP. You schedule the 27th leap
> seconds to happen just at the right time. When you're just 25 seconds off,
> someone forgot that update ;-)

If I do a "#cp query time" on my z/VM guests I get something like this:

00: CP QUERY TIME
00: TIME IS 14:01:14 CST WEDNESDAY 07/27/16
00: CONNECT= 99:59:59 VIRTCPU= 007:13.79 TOTCPU= 007:35.53

The interesting part is "CST", which stands for coordinated server time.
And this does not include leap seconds. That implies that your local time
for CP and CMS is not in UTC, no?

> If you don't care about z/OS, you might keep the HMC-defined offset at 0
> and run at UTC rather than TA1. When NTP injects the leap second, STP/ETR
> will work through the night and slowly adjust time again.

Why should STP adjust anything after NTP injected a leap second?!? The TOD
clock does not include leap seconds, there is nothing to adjust.
The NTP injected leap second will only show up in the system time offset
that is added to the TOD clock.

> A pragmatic approach could be to have a single virtual machine after z/VM
> IPL obtain UTC time (eg through my NTPDATE EXEC or a table with leap second
> moments) and issue a SET VTOD to correct the offset at IPL. The Linux
> guests could have the directory statement to say "I have what she has" and
> run all with the proper 26 seconds offset. Linux would see a TOD in UTC
> again. After that STP/ETR will steer the hardware TOD to stay on time.
> Unfortunately this does not handle the moment when the leap second is
> injected.

Well, STP will report the TOD time stamp when a leap second is due. How to
do the leap second clock drift is up to the OS.

--
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/

Re: Back to the future?

[Rob van der Heij]

On 26 July 2016 at 19:33, Marcy Cortes 
wrote:

> Martin 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).
>
> This kind of implies that if I disable NTP on a server and reboot, it
> should be 26 seconds or so off.
> It's not.   I'm seeing .003590 offset on one I just tried.
>

Unfortunately NTP does not work well inside a virtual machine. The
algorithms are designed with network latency and eliminate those aspects.
The latency in dispatching a virtual machine is rather different. I have
seen an ntpd steered guest have serious mood swings, larger than the
dispatch latency. And 3.5 ms is pretty good. If you need reasonable time in
Linux, you might want to adjust clocks once during boot and not run ntpd
after that. Go read the 100 pages on para-virtualized RTC on other
platforms and notice there are still guests that drift away.

Last time I looked, the HWCLOCK was broken for s390x. It is meant to deal
with the cheap RTC chip to keep time over periods of power-off and primed
the clock the wrong way (confusing ntpd and make the clock jump after a
while).

A z/OS system requires the hardware TOD to run TA1 and converts TOD clock
values (current or historic) it uses a table with 26 ^w 27 TOD values where
leap seconds were added. If you are close with z/OS your z/VM TOD runs TA1.
Since z/VM does not have that table, your UTC (and local time for CP and
CMS things) will be off by the 26 leap seconds unless you change it at IPL
(which goes into the LPAR offset). The HMC has the current number of leap
seconds defined to obtain the TA1 from NTP. You schedule the 27th leap
seconds to happen just at the right time. When you're just 25 seconds off,
someone forgot that update ;-)

If you don't care about z/OS, you might keep the HMC-defined offset at 0
and run at UTC rather than TA1. When NTP injects the leap second, STP/ETR
will work through the night and slowly adjust time again.

A pragmatic approach could be to have a single virtual machine after z/VM
IPL obtain UTC time (eg through my NTPDATE EXEC or a table with leap second
moments) and issue a SET VTOD to correct the offset at IPL. The Linux
guests could have the directory statement to say "I have what she has" and
run all with the proper 26 seconds offset. Linux would see a TOD in UTC
again. After that STP/ETR will steer the hardware TOD to stay on time.
Unfortunately this does not handle the moment when the leap second is
injected.

Rob

--
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/

Re: Back to the future?

[Martin Schwidefsky]

On Tue, 26 Jul 2016 17:33:31 +
Marcy Cortes  wrote:

> Martin 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).
>
> This kind of implies that if I disable NTP on a server and reboot, it should 
> be 26 seconds or so off.
> It's not.   I'm seeing .003590 offset on one I just tried.

LPAR or z/VM? I just tried as well and I do get the 26 second offset for both 
LPAR and z/VM.
How did you get the timestamps you are comparing?

--
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/

Re: Back to the future?

[Martin Schwidefsky]

On Tue, 26 Jul 2016 17:29:24 +0200
WF Konynenberg  wrote:

> Hi Martin,
>
> On 07/26/2016 04:12 PM, Martin Schwidefsky wrote:
> > On Tue, 26 Jul 2016 10:37:33 +0200
> > WF Konynenberg  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 
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 

> >> 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_