Leap Seconds and how they are handled by Meinberg Devices and NTP
Leap Seconds Overview
The basic time for mostly all of the world's local time zones is called Coordinated Universal Time, UTC, which is derived from a bunch of atomic clocks which are distributed in several countries all over the world.
The rotation of the earth is not very constant and varies a bit over time, while decreasing the mean rotation speed slowly. This is the reason why so called leap seconds are inserted into the UTC time scale, they adjust process of the UTC time to the real earth rotation.
Leap second in UTC, http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html
Extrapolations of the difference ( TI - UT1 ), http://www.ucolick.org/~sla/leapsecs/dutc.html
The International Earth Rotation Service, IERS, is measuring the true earth rotation and determines when a leap second has to be inserted. Insertion of a leap second is always scheduled for the end of the last day of a month, preferably at the end of June or December, at UTC midnight. In the past all leap seconds had been inserted at either one of those times. Announcements whether a leap second is scheduled or not are published by the IERS in their Bulletin C. The current Bulletin C is published about half a year before the next possible date for a leap second.
The IERS Bulletin C #30 from July 2005 announced a leap second to be inserted at the end of December 31, 2005, at UTC midnight. This was the first leap second that had been inserted since the end of 1998. This is why many applications which had been developed during the previous 7 years could not handle the leap second correctly.
Since the leap second was inserted at the same moment all over the world, the local (civil) time of the insertion depends on the local time offset from UTC, e.g. if the time zone is UTC+3h then the leap second will be inserted when the wall clocks show 3 hours after midnight.
The standard way to count UTC time across a leap second is:
2005-12-31 23.59.57 2005-12-31 23.59.58 2005-12-31 23.59.59 2005-12-31 23.59.60 <-- leap second 2006-01-01 00.00.00 2006-01-01 00.00.01 2006-01-01 00.00.02In local time counting depends on the time zone offset, e.g. for UTC+3h you would observe the following:
2006-01-01 02.59.57 2006-01-01 02.59.58 2006-01-01 02.59.59 2006-01-01 02.59.60 <-- leap second 2006-01-01 03.00.00 2006-01-01 03.00.01 2006-01-01 03.00.02Leap seconds are a discontinuity of civil time. The time does not continue to increase monotonically but it is stepped by one second. Let's have a look at the time stamps of a leap second which is inserted, and the second after that leap second:
2005-12-31 23.59.60 <-- leap second 2006-01-01 00.00.00We can normalize the time and date of the leap second:
60 seconds are 1 minute, which lets the minutes increment from 59 to 60
60 minutes are 1 hour, which lets the hours increment from 23 to 24
24 hours are 1 day, which lets the date increment, and so on.
Finally we can say that both lines represent exactly the same time, or 2 consequent seconds have the same time stamp.
Several time dissemination services also propagate the announcement of a leap second after this has been determined by the IERS. This includes for example the German long wave transmitter DCF77 and the satellite based navigation system GPS, so receivers which decode the signals from those systems can also decode the leap second announcement. Applications which read the time from those receivers can also determine the leap second announcement if this information is included in the applied protocol, e.g the time string transmitted by the receiver.
Please note that time code receivers can only pass the announcement of a leap second to the application, and count the time correctly over that period. It's the task of the application and/or operating system to handle that leap second correctly.
NTP and Leap Seconds
NTP is capable of dealing with leap seconds.
Leap second announcements can be received from an upstream NTP server,
an external radio clock or GPS receiver, or a
leap second table file.
If an NTP daemon detects a leap second announcement it passes the announcement on to its clients, and notifies its own operating system clock of the upcoming leap second, if the operating system is aware of leap seconds. For OS support of leap seconds see below.
Please note that the time stamps NTP uses internally just counts the UTC seconds after the epoche, i.e. since year 1900. NTP does neither care about time zones, nor does it use human readable date and time as mentioned in the description of the refclock time strings above.
Of course the internal time stamps may be converted back to human readable format in log or debug messages, but since that conversion may be ambiguous (i.e. the inserted leap second and the next second may have the same time stamp) you will never observe the second counting from 59 to 60 and then 0.
Radio Clocks and GPS Receivers
DCF77 radio clocks and GPS receivers manufactured by Meinberg send by default a time string once per second which contains date and time in a human readable format, including some status characters one of which announces an upcoming leap second.
In the example output below, <STX> and <ETX> refer to the ASCII characters STX (code 0x02) and ETX (code 0x03).
Announcement of the leap second starts 59 minutes before the leap second:
<STX>D:31.12.05;T:6;U:23.00.57; U <ETX> <STX>D:31.12.05;T:6;U:23.00.58; U <ETX> <STX>D:31.12.05;T:6;U:23.00.59; U <ETX> <STX>D:31.12.05;T:6;U:23.01.00; UA<ETX> <STX>D:31.12.05;T:6;U:23.01.01; UA<ETX> <STX>D:31.12.05;T:6;U:23.01.02; UA<ETX>This is to be compatible with DCF77 receivers, where the LF transmitter starts sending the announcement in the first minute, but the clock can decode those bits only at the end of the first minute, so transmission of the announcement in the serial data stream starts at the second minute.
This happens when the leap second is inserted:
<STX>D:31.12.05;T:6;U:23.59.57; UA<ETX> <STX>D:31.12.05;T:6;U:23.59.58; UA<ETX> <STX>D:31.12.05;T:6;U:23.59.59; UA<ETX> <STX>D:31.12.05;T:6;U:23.59.60; U <ETX> <-- leap second <STX>D:01.01.06;T:7;U:00.00.00; U <ETX> <STX>D:01.01.06;T:7;U:00.00.01; U <ETX> <STX>D:01.01.06;T:7;U:00.00.02; U <ETX>Please note that the announcement has already disappeared during the leap second. However, the seconds will be transmitted as 59, 60, 00 which matches the standard way of counting during a leap second.
Please note also that the leap second is introduced at UTC midnight. The 'U' status character in the example time strings above indicates that the time in the string is UTC. If the time string contained local time then the hours rolled over depending on the selected local time offset from UTC.
For example if the time string contained CET = UTC+1h, the output across the leap second would look like this:
<STX>D:01.01.06;T:7;U:00.59.59; A<ETX> <STX>D:01.01.06;T:7;U:00.59.60; <ETX> <-- leap second <STX>D:01.01.06;T:7;U:01.00.00; <ETX>Please note that a space is sent here instead of the 'U' status character in order to indicate that the time in the string is local time (daylight saving not active) depending on the configured time zone.
The full specification of the Meinberg Standard Time String format is
available under the following link:
IRIG Time Codes
IRIG time codes are often used to synchronize time between computers and other devices via cables or fiber optic connections.
Several IRIG frame types have been specified to transport time information between two IRIG devices. Most of the commonly used IRIG frames carry the day-of-year and the current time, but they do neither contain the year number which would be required to convert the day-of-year to a calendar date unambiguously in leap years and non-leap years, nor the UTC offset of the transported time, or a leap second announcement.
The IRIG frame type IEEE1344 contains all this information. However, by specification the leap second is announced only about 60 seconds before it actually occurs.
If such an IRIG receiver is used as a reference time source for NTP then there's a good chance the NTP daemon misses the leap second announcement at a polling interval of 64 seconds and thus is unable to handle the leap second correctly. Even if the NTP daemon received the leap second announcement, it was too late to pass the announcement on to the clients, so most of the NTP clients would probably miss the leap second.
This is the reason why in general a leap second file should be installed for NTP if an IRIG receiver is used as reference time source.
Meinberg LANTIME NTP Servers
Most Meinberg LANTIME NTP servers have a built-in reference clock, e.g. a radio clock, or a GPS receiver which receive the leap second announcement from their primary time source, e.g. the long wave transmitter DCF77, or the GPS satellites.
The NTP server software (ntpd) reads the time from its reference clock once every 64 seconds. Since the time string formats normally used by Meinberg reference clocks support the leap second announcement, ntpd detects the announcement at least 64 seconds after the refclock has started to announce it.
The NTP server passes the announcement to its NTP clients by setting the leap indicator flag in the NTP network packets accordingly until the leap second has happened.
During the leap second the LANTIME's ntpd responds with the same time stamp to any client request. Since NTP clients usually don't query the time in intervals shorter than 64 seconds, they normally won't even notice this, but they can evaluate the leap second announcement which is passed in to them as part of the network packets.
We have run a test program against a Meinberg LANTIME NTP server which queries the NTP server 4 times per second. The LANTIME is fed by a reference time source which supplies the leap second inclusive of the announcement as described above. The program prints the time stamp received from the NTP server, and the time stamp converted to human readable date and time.
Here is the result:
C76199FE.ED888F86 2005-12-31 23:59:58.927864 C76199FF.2E4723AA 2005-12-31 23:59:59.180772 C76199FF.6F09C7FF 2005-12-31 23:59:59.433742 C76199FF.B0320104 2005-12-31 23:59:59.688262 C76199FF.F1167664 2005-12-31 23:59:59.941748 C76199FF.FD09E12A 2005-12-31 23:59:59.988431 <-- leap second C76199FF.FD09E12A 2005-12-31 23:59:59.988431 <-- leap second C76199FF.FD09E12A 2005-12-31 23:59:59.988431 <-- leap second C76199FF.FD09E12A 2005-12-31 23:59:59.988431 <-- leap second C7619A00.35E37585 2006-01-01 00:00:00.210501 C7619A00.76A22B38 2006-01-01 00:00:00.463411 C7619A00.B770BD01 2006-01-01 00:00:00.716563 C7619A00.F823FAB1 2006-01-01 00:00:00.969298 C7619A01.38EEF1BA 2006-01-01 00:00:01.222395 C7619A01.79AF6C69 2006-01-01 00:00:01.475332 C7619A01.BA76965F 2006-01-01 00:00:01.728371Please note the 4 same time stamps which are received during the leap second.
Leap Second Handling by Operating SystemsSome operating system clocks are aware of leap seconds, others are not. If an operating system is aware of leap seconds then NTP can pass the leap second announcement to the kernel and it's up to the kernel which way to handle it. Basically there are 3 ways, each of them has specific advantages and disadvantages:
- The system clock can be stepped back by 1 second at the end of the
leap second. Using this method the time is always exact.
However, it does not increase monotonically, it introduces a discontinuity
(in fact just how a leap second is defined).
Stepping back the time may perturb the ordering
of events based on time stamps since an event which has happened shortly
after another event may receive a time stamp which is before
the time stamp of the other event. This may affect data base applications,
etc, which strongly rely on the ordering of events.
- The system clock can be hold for 1 second during the leap second.
This means that the time must not be stepped back but increases
monotonically, thus lessening the negative effects on data base
applications. The system clock returns always the same time
stamp during the leap second, and the time error increases from 0
to 1 second.
- The system clock can be slewed to compensate the discontinuity
introduced by the leap second. This lets the system time increase strongly
monotonically since all time stamps happen in the correct order, and there
are no 2 of the same time stamps. On the other hand, the system time is "wrong"
until slewing has completed.
Linux kernels and most other Unix-like systems care about the leap seconds and handle them correctly. Some systems even add a notification to the system log when the leap second is inserted.
Some operating systems or older kernels may not care about the leap second announcement, so the 1 second offset after the leap second has been inserted is compensated by stepping the clock back. This may happen with some delay, depending on the NTP polling interval and implementation of the operating system clock.
The Windows system clock does not know about leap seconds, either. However, there is a precompiled version of ntpd for Windows available which is capable of slewing the Windows system time quickly in order to account for the insertion of a leap second, without affecting the clock synchronization loop provided by ntpd.
Of course this works only successfully if also the upstream servers or reference time sources also behave well and announce and handle the leap second correctly. We have recorded the time synchronization behaviour during the leap second and present the results below.
Synchronization of the Windows system time
Leap Second under Windows disciplined by NTPThe graphs below illustrate synchronization of the Windows system time by ntpd over the leap second at the end of December, 2005.
The test environment includes ntpd (firstname.lastname@example.org) from our NTP download page http://www.meinbergglobal.com/english/sw/ntp.htm#ntp_nt running on a PC with a Pentium 4 CPU (3.2 GHz), under Windows XP SP2. The NTP service was configured to use a single Meinberg LANTIME/GPS NTP server as upstream server on the local network.
Data has been recorded by computing the difference between the interpolated Windows system time disciplined by ntpd, and the time stamp taken from a Meinberg GPS PCI card which provides an accuracy of better than 1 microsecond.
The first graph below shows the measured time difference in milliseconds, and the Windows tick adjustment values over time. The time scale is in seconds after start of recording. At the time of leap second insertion there's a 1000 millisecond peak, and the tick adjustment is reduced to half the normal value for a short period:
In the graphs above, the lines before and after the leap second are quite flat, so the next graph shows the interesting values with higher resolution:
As can be seen above, the time synchronization loop has not been affected by the inserted leap second. Taking into account that the Windows time on this system normally ticks in 15 millisecond increments only, and higher resolution is only achieved by interpolation, the results are quite good.