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:[email protected]] On Behalf Of WF Konynenberg Sent: Monday, July 25, 2016 2:37 PM To: [email protected] 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 [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/
