Schaltsekunden und deren Auswertung durch Funkuhren und NTP

Inhalt:


Übersicht Schaltsekunden

Die Grundlage für die meisten Zeitzonen der Welt ist die Weltzeit UTC, Coordinated Universal Time, die von einer Reihe von Atomuhren, abgeleitet wird, die über mehrere Länder der Welt verteilt sind.

Die Drehung der Erdkugel verläuft nicht so gleichmäßig, wie man zuerst vermuten würde. Stattdessen variiert sie leicht mit der Zeit, wobei sich die mittlere Rotationsgeschwindigkeit verringert. Um den Verlauf der UTC-Zeit an die tatsächliche Erddrehung anzupassen, werden von Zeit zu Zeit sogenannte Schaltsekunden in die UTC-Zeitskala eingefügt.

Eine Übersicht über den Verlauf der Erddrehung findet man auf einer Seite des Observatoriums von Paris:
Leap second in UTC, http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html

Der International Earth Rotation and reference Service, IERS, hat die Aufgabe, die Rotation der Erde zu vermessen und legt fest, wann eine Schaltsekunde einzufügen ist. Das Einfügen einer Schaltsekunde erfolgt immer um Mitternacht UTC am letzten Tag eines Monats, vorzugsweise am letzten Tag im Juni oder Dezember. Bisherige Schaltsekunden wurden immer zu einem dieser beiden Zeitpunkte eingefügt. Ankündigungen, ob eine Schaltsekunde eingefügt wird oder nicht, werden vom IERS in ihrem Bulletin C veröffentlicht. Das aktuelle Bulletin C erscheint ungefähr 6 Monate vor dem nächstm&oml;glichen Zeitpunkt für eine Schaltsekunde.

Das IERS Bulletin C Nr. 52 vom Juli 2016 kündigt eine Schaltsekunde zum Ende des 31. Dezember 2016 um Mitternacht UTC an.

Da eine Schaltsekunde weltweit zum gleichen Zeitpunkt eingefügt wird, hängt die Ortszeit der Einfügung von der Zeitzone ab, in der man sich befindet. Die Mitteleuropäische Zeit z.B. ist UTC + 1 Stunde, daher findet die Einfügung um 1 Uhr Ortszeit statt. Während also in Europa die Schaltsekunde während der Nacht eingefügt wird, passiert dies z.B. in den USA oder in Asien während der normalen Arbeitszeit.

Während einer Schaltsekunde erfolgt die Zählung der UTC-Zeit wie folgt:

2016-12-31 23.59.57
2016-12-31 23.59.58
2016-12-31 23.59.59
2016-12-31 23.59.60 <-- Schaltsekunde
2017-01-01 00.00.00
2017-01-01 00.00.01
2017-01-01 00.00.02
Für die Ortszeit dagegen hängt der Stundenwert vom Unterschied zwischen der Zeitzone von UTC ab. Für die Mitteleuropäische Zeit (UTC+1h) z.B. sieht der Ablauf wie folgt aus:

2017-01-01 00.59.57
2017-01-01 00.59.58
2017-01-01 00.59.59
2017-01-01 00.59.60 <-- Schaltsekunde
2017-01-01 01.00.00
2017-01-01 01.00.01
2017-01-01 01.00.02
Schaltsekunden sind eine Unstetigkeit im Zeitverlauf. Die Zeit verläuft nicht mehr gleichmäßig weiter, sondern springt um eine Sekunde zurück, wie man am Beispiel der Schaltsekunde und der darauffolgenden Sekunde sehen kann:

2016-12-31 23.59.60 <-- Schaltsekunde
2017-01-01 00.00.00
Datum und Uhrzeit der Schaltsekunde können normalisiert werden:
60 Sekunden sind eine Minute, wodurch der Minutenwert von 59 auf 60 erhöht wird
60 Minuten sind eine Stunde, wodurch der Stundenwert von 23 auf 24 erhöht wird
24 Stunden sind 1 Tag, wodurch das Datum weitergezählt wird, usw.
Letztendlich geben also beide Zeilen exakt die gleiche Zeit wieder, d.h., zwei aufeinanderfolgende Sekunden haben den gleichen Zeitstempel.

Die meisten Dienste, die auch die Zeit verbreiten, geben auch die Ankündigung der Schaltsekunde durch den IERS weiter, so z.B. der deutsche Langwellensender DCF77 und das satellitengestützte Navigationssystem GPS. Funkuhren und GPS-Empfänger sind also prinzipiell auch in der Lage, diese Ankündigung zu erkennen. Anwendungen, die die Zeit von diesen Geräten lesen, erhalten diese Ankündigung ebenfalls, wenn die entsprechende Information in dem verwendeten Protokoll, z.B. dem seriellen Zeittelegramm, enthalten ist.

Zu beachten ist, dass Funkuhren und andere Zeitempfänger lediglich die Ankündigung der Schaltsekunde an die Anwendung bzw. das Betriebssystem weiterreichen und natürlich auch die Zeitzählung über die Schaltsekunde hinweg korrekt vornehmen können. Es ist aber Aufgabe der Anwendungen bzw. des Betriebssystems, die Schaltsekunde korrekt zu verarbeiten.


Top

NTP und Schaltsekunden


NTP ist in der Lage, mit Schaltsekunden umzugehen. Die Ankündigung einer Schaltsekunde kann durch einen übergeordneten NTP-Server, eine externe Funkuhr bzw. einen GPS-Empfänger, oder durch ein Leap Second File (eine Datei mit einer Liste aller Schaltsekunden) erfolgen.

Wenn ein NTP-Daemon eine Schaltsekunden-Ankündigung erhält, gibt er diese an seine Clients weiter und teilt auch seinem Betriebssystem mit, dass eine Schaltsekunde zu erwarten ist, wenn das Betriebssystem dieses unterstützt. Einzelheiten zur Unterstützung von Schaltsekunden durch Betriebssysteme finden sich weiter unten.

Zu beachten ist, dass die von NTP intern verwendeten Zeitstempel lediglich die Sekunden nach Beginn einer bestimmten Epoche zählen, z.B. ab dem Jahr 1900. NTP kennt weder unterschiedliche Zeitzonen, noch verwendet es eine Zählweise von 59, 60, 00, wie sie im Beispiel unten für die Zeittelegramme verwendet wird.

Natürlich können die von NTP verwendeten Zeitstempel auch in ein lesbares Datums- und Zeitformat umgerechnet und ausgegeben werden. Da die Umrechnung jedoch wie oben beschrieben mehrdeutig ist (die Schaltsekunde und die darauffolgende Sekunde haben den gleichen Zeitstempel), wird man oft nicht den Sekundenverlauf 59 - 60 - 00 beobachten, sondern 59 - 59 - 00 oder 59 - 00 - 00.


Top

Funkuhren und GPS-Empfänger

Bereits einige Tage nachdem das Bulletin C eine Schaltsekunde angekündigt hat, beginnen die GPS-Satelliten mit der Aussending von Informationen zur kommenden Schaltsekunde. GPS-Empfänger wissen also bereits einige Monate im Voraus, dass eine Schaltsekunde naht. Obwohl die von GPS gesendeten Informationen zur Schaltsekunde auch das genaue Datum der Schaltsekunde erhalten, z.B. 31. Dezember 2016, gibt es leider einige GPS-Empfänger von anderen Herstellern, die eine Schaltsekunden-Ankündigung viel zu früh und für ein falsches Datum ausgeben, z.B. für Ende März oder Ende September. Meinberg-Geräte wie z.B. die LANTIME-Zeitserver mit eingebautem GPS-Empfänger erzeugen gegebenenfalls lediglich einen Log-Eintrag, wenn sie die Schaltsekunden-Informationen von den GPS-Satelliten emfangen, fügen die Schaltsekunde aber erst zum korrekten Zeitpunkt ein. DCF77-Funkuhren und GPS-Empfänger von Meinberg senden normalerweise sekündlich ein serielles Zeittelegramm, welches außer Datum und Uhrzeit auch einige Statuszeichen enthält, von denen eines die kommende Schaltsekunde ankündigt.

Im Beispiel unten stehen die Zeichen <STX> und <ETX> für die ASCII-Zeichen STX (Code 0x02) und ETX (Code 0x03).

Die Ankündigung der Schaltsekunde beginnt 59 Minuten vor der Schaltsekunde selbst:

<STX>D:31.12.16;T:6;U:23.00.57;  U <ETX>
<STX>D:31.12.16;T:6;U:23.00.58;  U <ETX>
<STX>D:31.12.16;T:6;U:23.00.59;  U <ETX>
<STX>D:31.12.16;T:6;U:23.01.00;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.01.01;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.01.02;  UA<ETX>
Der Grund dafür ist die angestrebte Kompatibilität mit unseren DCF77-Empfängern. DCF77 beginnt mit der Aussendung der Ankündigung in der ersten Minute der letzten Stunde vor dem Ereignis. Der DCF77-Empfänger kann jedoch die Ankündigung erst am Ende der ersten Minute sicher erkennen und beginnt daher mit der Ausgabe der Ankündigung in der zweiten Minute.

Über die Schaltsekunde hinweg werden folgende Zeittelegramme ausgegeben:

<STX>D:31.12.16;T:6;U:23.59.57;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.59.58;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.59.59;  UA<ETX>
<STX>D:31.12.16;T:6;U:23.59.60;  U <ETX> <-- Schaltsekunde
<STX>D:01.01.17;T:7;U:00.00.00;  U <ETX>
<STX>D:01.01.17;T:7;U:00.00.01;  U <ETX>
<STX>D:01.01.17;T:7;U:00.00.02;  U <ETX>
Zu beachten ist, dass das Ankündigungszeichen bereits während der Schaltsekunde wieder zurückgenommen wird. Die Sekunden werden als 59, 60, 00 gezählt, was der normalen Zählweise entspricht.

Wie bereits erwähnt, wird die Schaltsekunde um UTC Mitternacht eingefügt. Das Statuszeichen 'U' in den Zeittelegrammen oben gibt an, dass das Zeittelegramm die UTC-Zeit enthält. Wenn das Zeittelegramm dagegen eine von UTC abweichende Ortszeit enthält, ist die Zeit in den Zeittelegrammen um den entsprechenden UTC-Offset verschoben.

Wenn die Zeittelegramme z.B. MEZ = UTC+1h enthalten, sieht die Ausgabe über die Schaltsekunde folgendermaßen aus:

<STX>D:01.01.17;T:7;U:00.59.59;   A<ETX>
<STX>D:01.01.17;T:7;U:00.59.60;    <ETX> <-- Schaltsekunde
<STX>D:01.01.17;T:7;U:01.00.00;    <ETX>
Im letzen Beispiel wird statt des Statuszeichens 'U' ein Leerzeichen ausgegeben, um anzugeben, dass es sich bei der ausgegebenen Zeit um die Ortszeit handelt (Sommerzeit nicht aktiv), entsprechend der im Empfänger konfigurierten Zeitzone.

Die vollständige Spezifikation des Meinberg Standard Zeittelegramm-Formats ist unter dem folgenden Link verfügbar:
https://www.meinberg.de/german/specs/timestr.htm.


Top

IRIG-Zeitcodes

IRIG-Zeitcodes werden häufig verwendet, um die Zeit zwischen Computern und anderen Geräten mit Hilfe von Kabeln oder Glasfaserleitungen zu synchronisieren.

Zur Übertragung der Zeitinformationen wurden mehrere IRIG-Formate spezifiziert. Die meisten der gebräuchlichen Formate enthalten den Jahrestag und die aktuelle Zeit, aber weder die Jahreszahl, die benötigt würde, um sowohl in einem Schaltjahr als auch in anderen Jahren aus dem Jahrestag das korrekte aktuelle Datum zu bestimmen, noch den UTC-Offset der übertragenen Zeit, und auch keine Schaltsekundenankündigung.

Die IRIG-kompatiblen Zeitcode-Formate IEEE 1344 und IEEE C37.118 enthalten zwar diese Informationen, jedoch erfolgt per Definition die Ankündigung der Schaltsekunde erst ca. 60 Sekunden bevor die Schaltsekunde eingefügt wird.

Wenn ein solcher IRIG-Empfänger als Zeitquelle für NTP verwendet wird, ist es leicht möglich, dass der NTP-Daemon bei einem Polling-Intervall von 64 Sekunden oder sogar größer diese Schaltsekundenankündigung überhaupt nicht mitbekommt und er daher die Schaltsekunde verpasst. Selbst wenn er die Schaltsekundenankündigung noch mitbekommt, ist es wahrscheinlich zu spät, diese an seine Clients weiterzugeben, so dass wahrscheinlich die Clients die Schaltsekunde nicht rechtzeitig berücksichtigen können.

Aus diesem Grund ist es sinnvoll, bei Verwendung von IRIG als Zeitquelle für NTP für NTP generell eine Datei mit einer Tabelle von Schaltsekunden zu verwenden. Grundsätzliche Informationen zur Verwendung von IRIG-Zeitcodes findet man auch in dem Whitepaper IRIG Time Code Basics


Top

Meinberg LANTIME NTP-Server

Die meisten Meinberg LANTIME NTP-Server haben eine eingebaute Funkuhr oder einen eingebauten GPS-Empfänger, die die Schaltsekunden-Ankündigung von ihrer jeweiligen Zeitquelle erhalten.

Die NTP-Software (ntpd) liest nur alle paar Sekunden die Zeit von der Funkuhr. Da die normalerweise von Meinberg verwendeten Zeittelegramm-Formate die Ankündigung der Schaltsekunde enthalten, erkennt der NTP-Daemon die Ankündigung spätestens ein paar Sekunden, nachdem die Funkuhr mit der Übertragung der Ankündigung begonnen hat.

Der NTP-Server gibt die Schaltsekunden-Ankündigung an seine Clients weiter, indem er eine entsprechende Kennung in den Netzwerk-Paketen setzt.

Alle Anfragepakete während der Schaltsekunde beantwortet der LANTIME NTP-Server mit dem gleichen Zeitstempel, d.h. die interne Systemzeit wird praktisch eine Sekunde lang angehalten. Da NTP-Clients normalerweise niemals in kürzeren Intervallen als 64 Sekunden anfragen, werden sie dieses nicht einmal bemerken. Allerdings bekommen die Clients auch die nahende Schaltsekunde mitgeteilt, so dass auch sie die Schaltsekunde entsprechend berücksichtigen können.

Wir haben mit Hilfe eines Testprogramms 4 Anfragen pro Sekunde an einen Meinberg LANTIME NTP-Server gesendet, dessen Referenzzeitquelle den Schaltsekundenübergang inklusive der Ankündigung ausgibt, wie oben beschrieben. Das Programm zeigt die vom NTP-Server erhaltenen Zeitstempel sowie Datum und Zeit im menschenlesbaren Format an.

Hier ist das Ergebnis:

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 <-- Schaltsekunde
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- Schaltsekunde
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- Schaltsekunde
C76199FF.FD09E12A  2005-12-31 23:59:59.988431 <-- Schaltsekunde
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.728371
Zu beachten sind die 4 gleichen Zeitstempel, die während der Schaltsekunde zurückgeliefert werden.

Top

Betriebssysteme

Unterstützung von Schaltsekunden durch Betriebssysteme

Einige Betriebssystem enthalten Unterstützung für Schaltsekunden, andere jedoch nicht. Wenn ein Betriebssystem Schaltsekunden unterstützt, kann NTP die Ankündigung an den Kernel weiterreichen. Es ist dann Sache des Kernels, auf welche Weise er eine Schaltsekunde berücksichtigt. Grundsätzlich gibt es 3 Möglichkeiten, von denen jede ihre Vor- und Nachteile hat:

  1. Die Systemzeit kann am Ende der Schaltsekunde um eine Sekunde zurückgestellt werden. Auf diese Weise ist die Systemzeit zwar immer exakt, aber sie verläuft nicht stetig, sondern enthält einen Sprung zurück, so wie die Schaltsekunde ja definiert ist. Ein Rückwärtssprung der Systemzeit kann sich jedoch sehr störend auf Programme auswirken, die die Reihenfolge von Ereignissen auf Basis zugeordneter Zeitstempel einordnen, denn ein Ereignis, welches kurz nach einem anderen Ereignis auftrat, kann einen Zeitstempel erhalten, welcher vor dem Zeitstempel des anderen Ereignisses liegt. Betroffen davon sind z.B. Datenbankprogramme, die stark von einer korrekt sortierten Reihenfolge von Ereignissen abhängen.

  2. Die Systemzeit kann während der Schaltsekunde angehalten werden. Das bedeutet, dass die Zeit nicht zurückgestellt werden muß, sondern kontinuierlich weiterläuft. Dadurch werden negative Auswirkungen auf Datenbank-Applikationen vermindert. Die Systemuhr liefert während der Schaltsekunde immer die gleiche Zeit zurück, und der Zeitfehler der Systemuhr steigt während der Schaltsekunde von 0 auf 1 Sekunde an.

  3. Die Systemzeit kann verlangsamt werden, bis die durch die Schaltsekunde eingefügte Zeitdifferenz kompensiert wurde. Auf diese Weise verläuft die Systemzeit stetig, es werden keine gleichen Zeitstempel zurückgelesen, und alle Zeitstempel haben die richtige Reihenfolge. Auf der anderen Seite geht die Systemuhr "falsch", bis der Kompensationsvorgang abgeschlossen ist.

Auf welche Weise eine Schaltsekunde verarbeitet wird, hängt also in erster Linie davon ab, auf welche Weise dies im Betriebssystem implementiert wurde, wenn überhaupt eine Verarbeitung implementiert wurde.

Linux-Kernels sowie die meisten anderen Unix-ähnlichen Betriebssysteme erkennen und verarbeiten eine Schaltsekunde problemlos und erzeugen teilweise auch einen entsprechenden Log-Eintrag, wenn die Schaltsekunde eingefügt wird.

Einige Betriebssysteme oder ältere Kernels enthalten keine Unterstützung für Schaltsekunden. In diesen Fällen wird normalerweise die Systemzeit von NTP um eine Sekunde zurückgestellt. Dies kann mit einiger Verzögerung erfolgen, abhängig vom NTP-Abfrageintervall und der Implementierung der Systemuhr des Betriebssystems.

Die Windows-Systemzeit kennt keine Schaltsekunden. Allerdings gibt es eine vorcompilierte Version von ntpd für Windows, welche die Systemzeit im Fall einer Schaltsekunde sehr schnell nachführt, ohne den NTP-Filteralgorithmus zu stören.

Natürlich funktioniert das nur dann problemlos, wenn auch alle Referenzzeitquellen wie vorgeschaltete NTP-Server die Schaltsekunde korrekt ankündigen und verarbeiten. Wir haben die Qualität der Zeitsynchronisierung unter Windows während der letzten Schaltsekunde mitprotokolliert und die Ergebnisse weiter unten dargestellt.


Top

Synchronisation der Windows-Systemzeit

Windows Zeitsynchronisation durch NTP über eine Schaltsekunde

Die Grafiken unten zeigen den Verlauf der Synchronisation der Windows-Systemzeit durch ntpd über die Schaltsekunde Ende Dezember 2005.

Zum Test wurde das NTP-Paket (ntp-4.2.0b@1.1436mbg-xmas-o-win32) von unserer NTP-Downloadseite https://www.meinberg.de/german/sw/ntp.htm#ntp_nt auf einem PC mit Pentium 4 CPU (3.2 GHz) unter Windows XP SP2 installiert. Als Referenzzeitquelle für den NTP-Service wurde ein einziger Meinberg LANTIME/GPS NTP-Server im lokalen Netzwerk konfiguriert.

Die Daten wurden erfasst durch die Bestimmung der Differenz zwischen der von ntpd synchronisierten, interpolierten Windows-Systemzeit und der Zeit von einer Meinberg GPS PCI-Express-Karte, welche die Zeit mit einer Genauigkeit besser als 1 Mikrosekunde bereitstellt.

Die erste Grafik zeigt den Verlauf der gemessenen Zeitabweichung in Millisekunden und die Tick-Adjust-Werte der Windows Systemuhr über die Zeit. Die Zeitskala ist in Sekunden ab dem Start des Protokolls. Zum Zeitpunkt der Schaltsekunde ist deutlich eine Spitze von 1000 Millisekunden zu sehen. Dementsprechend ist auch zu sehen, wie der Tick-Adjust-Wert kurzzeitig auf den halben Nominalwert reduziert wird, um die Schaltsekunde zu kompensieren:

Darstellung - Schaltsekunde

In der Grafik oben verlaufen die Kurven vor und nach der Schaltsekunde ziemlich gerade, daher folgt eine weitere Grafik, die die interessierenden Werte mit höherer Auflösung zeigt:

Darstellung - Schaltsekunde

Wie in der Grafik oben ersichtlich ist, wird die Regelschleife der Zeitsynchronisierung nicht durch die Schaltsekunde beeinflußt. Wenn man berücksichtigt, dass die Windows-Systemuhr normalerweise nur in 15 Millisekunden-Schritten zählt und die höhere Auflösung nur durch Interpolation der Zeit zwischen den Timer-Ticks erreicht wird, sind die Ergebnisse mehr als zufriedenstellend.

Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact