Yes, when your hardware clock is not managed by NTP you cannot rely on it to
accurately initialize the system clock on boot, so you should force an NTP
clock sync ("jump") on startup. Otherwise the NTP smooth clock adjustment
could take quite a while to get the system clock synced.
Once the initial sync has happened, NTP should be able to keep the clock within
at most a few milliseconds accurate, even on a VM with some scheduling
artifacts.
Willy
On July 26, 2016 12:46:34 AM CEST, Marcy Cortes <marcy.d.cor...@wellsfargo.com>
wrote:
>Answering my own post.
>The latter HWCLOCK option is not for s390x (the code in /etc/init.d/ntp
>ignores it if set if s390* )
>
>But the former might be a good thing.
>On the handful of test servers I ran it on, it gave me a smaller offset
>as queried with Christian's ntpdate command (10ths of milliseconds as
>opposed to 1-3 milliseconds).
>
>
>-----Original Message-----
>From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
>Marcy Cortes
>Sent: Monday, July 25, 2016 3:12 PM
>To: LINUX-390@VM.MARIST.EDU
>Subject: Re: [LINUX-390] Back to the future?
>
>I don't think my problem is leap seconds. I'm talking maybe a second
>difference max between 2 linux servers (on z).
>We need to be accurate to the millisecond level.
>
>I see this in /etc/sysconfig/ntp
>
>
>## Type: boolean
>## Default: "no"
>#
># Force time synchronization befor start ntpd #
>NTPD_FORCE_SYNC_ON_STARTUP="no"
>
>## Type: boolean
>## Default: "no"
>#
># Force time synchronization of hwclock befor start ntpd # This works
>only if NTPD_FORCE_SYNC_ON_STARTUP is set # to yes.
>#
>NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="no"
>
>
>Wondering if maybe yes is needed in one or both of those.
>
>
>
>
>-----Original Message-----
>From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
>WF Konynenberg
>Sent: Monday, July 25, 2016 2:37 PM
>To: LINUX-390@VM.MARIST.EDU
>Subject: Re: [LINUX-390] Back to the future?
>
>Hi,
>
>I'm not entirely sure I'm reading this right.
>
>Having just read up on how both STP, NTP, and POSIX deal with leap
>seconds, it would appear to me that all these systems track leap
>seconds and thus as a general rule represent a time approaching the
>formal UTC time. The precise mechanisms used to track leap seconds
>vary, which may lead to minor deltas at the time of the actual leap
>seconds, but generally, my reading is that all 3 timescales should
>normally be in sync and roughly represent the current UTC time.
>
>If an STP and an NTP managed Linux POSIX clock are out of sync by
>approximately the number of leap seconds that occurred since 1972, then
>the logical conclusion would be that one or the other protocol is not
>handling leap seconds properly when setting the POSIX UTC system clock
>from the protocol reference clock.
>
>My reading is that NTP handles this transparently by automatically
>distributing the leap second information and adjusting the POSIX UTC
>time as appropriate.
>
>From reading some STP documentation, it would appear that it requires
>that leap seconds be manually managed by the administrator. If an
>administrator were to fail to do so, this might lead to an incorrect
>STP reference, leading to an incorrect POSIX UTC clock setting. On the
>other hand, the info I have is a bit sparse, but might suggest that the
>actual raw hardware TOD clock maintained by STP is not leap second
>corrected, and the leap second correction information is provided
>separately, to be applied by the OS. If the Linux kernel code reading
>this clock thinks this hardware clock is actually running at UTC (and
>not TAI with some fixed offset), then this might also lead to a 26
>second offset problem.
>
>The "right" set of zoneinfo files should (if I read things correctly)
>only be used on systems that do not actually run a correct POSIX UTC
>clock, but instead run their system clock at a fixed offset of 10
>seconds to TAI. This is not a normal setup. These zoneinfo files
>should not be used on a system where the POSIX UTC system clock is
>managed by a regular NTP configuration, as this would lead the system
>to report times with a constant 26 second offset from UTC, which is
>undesirable.
>
>I think it would be good to verify that the Linux POSIX UTC system
>clock as managed by STP (which I think simply means linux trusting the
>hardware clock to be correct) is indeed running at UTC and not at TAI
>with some offset.
>
>
>Comments and enlightenment welcomed.
>
>Willy
>
>On 07/25/2016 09:04 PM, Robert J Brenneman wrote:
>> In a heterogeneous environment if your non Z NTP systems are off by
>> roughly
>> 26 seconds compared to your STP managed Z Linux clocks it could be
>due
>> to
>> this:
>> https://access.redhat.com/articles/15145
>>
>> basically - the default Linux timezone files do not respect leap
>> seconds, but the long time mainframe operator does and sets up STP
>correctly.
>>
>> The fix is to either
>> 1) run NTP on Linux on Z and steer it away from the STP time ( bleh!)
>> 2) or run NTP on the non-Z Linux systems against an NTP server
>running
>> on Linux on Z ( hacky and gross )
>> 3) or to tell the non-Z linux systems to account for leap seconds by
>> using the 'right' zonefiles:
>> cp /usr/share/zoneinfo/right/America/Los_Angeles
>/etc/localtime
>>
>> be aware that (3) will probably break stuff if you make that setting
>> while applications are running. It is probably best to shut all
>> applications down, make the change, reboot, and then start
>> applications back up. Test, Test more, and Test again.
>>
>> Additionally - you should probably not use those 'right' zonefiles on
>
>> a Linux on Z environment under STP clocking since you don't want to
>> account for leap seconds twice. That would probably be bad.
>>
>> --
>> Jay Brenneman
>>
>>
>----------------------------------------------------------------------
>> 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/
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
----------------------------------------------------------------------
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/
