Operating System - HP-UX
1752817 Members
4331 Online
108789 Solutions
New Discussion юеВ

Re: HP Support Statement for XNTPD Leap Second Processing

 
SOLVED
Go to solution
Steven E. Protter
Exalted Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

I found this fascinating.

If not totally relavent to my job, I really, really enjoyed it.

I encourage others at HP do do this.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Uwe Zessin
Honored Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

Bill Hassell
Honored Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

So the recommendation is to set -x in /etc/rc.config.d/netdaemons for xntpd options? Since there is a minor bug in logging, will there be a patch that includes an updated man page with leap second info? Would a patch also be created for 11.00? Are there any concerns about running xntpd -x?

It appears that leap seconds may occur yearly but the exact date for this event is determined after extensive measurements. Here is a great article from the US Naval Observatory: http://tycho.usno.navy.mil/leapsec.html


Bill Hassell, sysadmin
Todd Whitcher
Esteemed Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

Bill,

There is a section in the man page that talks about slew. Its a little long so I did not want to post it. Users would have to determine if their applications would be affected. HP generally doesnt recommend using slew, see "man 1m xntpd"

At this time I don't think there is an enhancement to update the man pages but I can certainly check and if not request one.

Thanks for posting the link.

Todd
Sandman!
Honored Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

Awesome job in putting together this document and making the itrc community aware of its presence.

regards!
Todd Whitcher
Esteemed Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

Here are some additional references:

URL Reference

http://www.ntp.org/ntpfaq/NTP-s-time.htm#Q-TIME-LEAP-SECOND

During a leap second, either one second is removed from the current day, or a second is added. In both cases this happens at the end of the UTC day. If a leap second is inserted, the time in UTC is specified as 23:59:60. In other words, it takes two seconds from 23:59:59 to 0:00:00 instead of one. If a leap second is deleted, time will jump from 23:59:58 to 0:00:00 in one second instead of two. See also Section 5.2.



Laboratories:

http://tycho.usno.navy.mil/leapsec.html (Master Clock)
http://www.npl.co.uk/time/leap_second.html

Discussion about a leap second

http://www.ucolick.org/~sla/leapsecs/onlinebib.html

According to the IERS a leap second will be introduced Jan 1 2006.

http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

Other References
http://tf.nist.gov/general/leaps.htm

http://www.cl.cam.ac.uk/~mgk25/time/leap/

http://tf.nist.gov/timefreq/pubs/bulletin/leapsecond.htm

http://www.livescience.com/technology/050705_leap_second.html

http://www.leapsecond.com/

Enjoy and thanks for the feedback.

Todd

A. Clay Stephenson
Acclaimed Contributor

Re: HP Support Statement for XNTPD Leap Second Processing

Of course the other side of the coin is that UNIX time as measured in epoch seconds has no notion of leap seconds and every day has exactly 86400 seconds. This also means that functions like mktime() will silently coerce the seconds into the range 0-59.

Because the tidal forces are always making the days longer --- and moving the moon farther away ---, the leap seconds are always expected to be positive. There are other mechanism in play which cause the rotational period of the earth to vary but the tidal forces are the first-order forces. Because angular momentum must be conserved, about the only mechanism (other than a collision with a rather large body) that could cause a negative leap second to be added would be an incredibly violent tectonic event. In either of those cases, I doubt very much that knowing the "correct" time will matter very much.

There is also a movement to do away with leap seconds to make timekeeping easier although the astronomical community is very opposed to this.
If it ain't broke, I can fix that.
Fedon Kadifeli
Super Advisor
Solution

Re: HP Support Statement for XNTPD Leap Second Processing

What I understand from this explanation is that in HP-UX (with no -x option to xntpd) we will have a scenario like this:

23:59:58
23:59:59
00:00:00
00:00:00 <== "leap second occurred, stepped time back 1 second"
00:00:01

And not like this:

23:59:58
23:59:59
23:59:60
00:00:00
00:00:01

I am correct?
Fedon Kadifeli
Super Advisor

Re: HP Support Statement for XNTPD Leap Second Processing

Just out of my curiosity I wrote a simple program that logs the time roughly every 250 milliseconds to a file. A ran that program on several machines. I also looked at the system logs. Here are the results:

Linux systems:
==============
system1 (kernel: 2.6.9-22)
--------------------------
/var/log/messages:
Jan 1 01:59:59 system1 kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 02:29:06 system1 ntpd[2234]: kernel time sync enabled 0001

Results from my program:
...
01/01/06 01:59:58.866391
01/01/06 01:59:59.118342
01/01/06 01:59:59.370286
01/01/06 01:59:59.622226
01/01/06 01:59:59.874171
01/01/06 01:59:59.126121 <<=== Note here
01/01/06 01:59:59.378062
01/01/06 01:59:59.630009
01/01/06 01:59:59.881953
01/01/06 02:00:00.133904
...

system2 (kernel: 2.6.9-5):
--------------------------
/var/log/messages:
Jan 1 01:59:59 system2 kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 02:32:06 system2 ntpd[2132]: kernel time sync enabled 0001


system3 (kernel: 2.4.21-20):
----------------------------
/var/log/messages:
Jan 1 01:21:48 system3 ntpd[19207]: kernel time discipline status change 11
Jan 1 01:59:59 system3 kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 02:30:05 system3 ntpd[19207]: kernel time discipline status change 1

Results from my program:
...
01/01/06 01:59:58.935352
01/01/06 01:59:59.195363
01/01/06 01:59:59.455370
01/01/06 01:59:59.715380
01/01/06 01:59:59.975388
01/01/06 01:59:59.235399 <<=== Note here
01/01/06 01:59:59.495409
01/01/06 01:59:59.755416
01/01/06 02:00:00.015423
...

HP-UX
=====
system4 (kernel: B.11.00):
--------------------------
/var/adm/syslog/syslog.log:
Jan 1 02:00:01 system4 xntpd[1096]: leap second occurred, stepped time back 1 second

Results from my program:
...
01/01/06 01:59:58.927018
01/01/06 01:59:59.187032
01/01/06 01:59:59.447046
01/01/06 01:59:59.707136
01/01/06 01:59:59.967033
01/01/06 02:00:00.227297
01/01/06 02:00:00.487192
01/01/06 02:00:00.747122
01/01/06 02:00:01.007174
01/01/06 02:00:01.267101
01/01/06 02:00:01.527165
01/01/06 02:00:01.787064
01/01/06 02:00:02.047041
01/01/06 02:00:02.307016
01/01/06 02:00:02.567112
01/01/06 02:00:02.827070
01/01/06 02:00:02.087247 <<=== Note here
01/01/06 02:00:02.347235
01/01/06 02:00:02.607201
01/01/06 02:00:02.867181
01/01/06 02:00:03.127217
...

The results show that both Linux and HP-UX systems inserted the leap second roughly on time 02:00 am; this is because the systems run on EET (i.e., UTC+2) time zone.

Linux systems inserted the leap second AFTER 01:59:59, so my program logged the time period 01:59:59 - 02:00:00 two times (note that there was no time 01:59:60).

HP-UX systems inserted the leap second AFTER 02:00:01; but actually my program logged the time period 02:00:02 - 02:00:03 two times.

This is just an information for curious people like me. :)

The program is attached...