Zeit-Abgleich

Inhaltsverzeichnis

Nicht nur in E-Mails oder wenn ein Textverarbeitungsprogramm das Datum automatisch einsetzt, auch in anderen Anwendungen oder Systemfunktionen spielt die Zeit mit. Sie fließt beispielsweise in Log-Dateien, Kerberos-Tickets, SSL-Zertifikate, differenzielle Backups oder den Datenabgleich mit PDAs ein. Ganz direkt wirkt sie bei zeitgesteuerten Aktionen, etwa den Geplanten Tasks unter Windows, cron unter Unix oder wenn man einen digitalen Videorecorder etwa unter Linux betreibt.

Einmal gestellt, beginnt die in PCs und Macs integrierte Echtzeituhr wie jede Wand- oder Armband-Uhr, von der wahren Zeit wegzudriften, sie geht falsch. Für viele Anwendungen reicht es wohl, wenn die Systemuhr höchstens um wenige Minuten abweicht. Das schafft sie auch, wenn man sie einmal monatlich nachstellt. Solange die auf dem Mainboard steckende Batterie frisch ist, läuft das System dann halbwegs genau. Wird der Energiespeicher aber nach einigen Jahren schwächer, dann beginnt die Onboard-Uhr nach dem Mond zu gehen. Abweichungen von Stunden und Tagen sind dann keine Seltenheit. Später droht sogar der Verlust der BIOS-Konfiguration, höchste Zeit, eine neue Batterie einzusetzen.

Oft genügt eine Minutengenauigkeit jedoch nicht: Wer auf der Suche nach Fehlfunktionen in einem Netzwerk ist, dem helfen Logfiles auf den verschiedenen Maschinen oft weiter. Driften allerdings die internen Uhren der Rechner im Laufe der Zeit auseinander, dann lässt sich im Nachhinein irgendwann nicht mehr rekonstruieren, ob ein fehlerauslösendes Ereignis A auf Rechner X nun vor oder nach Ereignis B auf Server Y auftrat.

Bei Versuchsaufbauten etwa in der Forschung, bei denen mehrere PCs eine gemeinsame Messaufgabe erfüllen, ist eine möglichst genaue Synchronisation meist unerlässlich. Langzeitmessungen, bei denen ein Rechner über Wochen oder Monate kontinuierlich Daten aufzeichnet, würden unter der Drift der PC-internen Uhr ebenfalls leiden.

Für einzelne Rechner mag es genügen, eine Funkuhr anzuschließen, die den Langwellen-Zeitzeichensender DCF77 empfängt, das kodierte Zeitsignal auswertet und den Rechner sekundengenau hält. Edlere Ausführungen nutzen dazu Satellitensignale des Global Positioning System (GPS). Beide Lösungen kosten Geld, brauchen eventuell eine separate Stromversorgung und belegen eine Schnittstelle am PC.

Langwellenempfang funktioniert meist auch innerhalb von Gebäuden, aber bisweilen können schon Blechjalousien das DCF77-Signal beeinträchtigen, was zu Aussetzern führt. Platziert man eine DCF77-Uhr nah neben einem Fernsehgerät, dann ist es spätestens zur Tagesschau mit genauer Funk-Zeit oft vorbei: Die fünfte Oberwelle der TV-Horizontalablenkung (5 × 15,625 = 78,125 kHz) liegt sehr dicht beim Zeitsignal (77,5 kHz) und stört dessen Empfang. Bei bestimmten Kombinationen von Auflösung und Bildwiederholfrequenz, zum Beispiel 1280 × 1024 Bildpunkte und 75 Hertz, kann auch ein PC-Röhrenmonitor in dem Bereich senden. Mit diesem Effekt hat eine GPS-Uhr zwar kein Problem, aber dafür muss man ihre Antenne so aufstellen, dass sie wenigstens einen Teil des Himmels und die dort kreisenden GPS-Satelliten sieht.

Zwar betreibt beispielsweise die Physikalisch-Technische Bundesanstalt (PTB), Hüterin der gesetzlichen Zeit in Deutschland, einen Modem-Server, den man abfragen kann, aber das kostet auch jedes Mal ein paar Cent. Im Laufe der Zeit kommt die Modemabfrage teurer als eine Funkuhr.

Eine alternative Quelle für die Zeit stellt das ISDN dar. Allerdings ist auch das nicht unbedingt der Weisheit letzter Schluss: Die ISDN-Zeit kann von der gesetzlichen Zeit bis zu einer Minute differieren, sogar mit unterschiedlichem Fehler zwischen verschiedenen Vermittlungsstellen. Außerdem überträgt das ISDN-System die Zeit nur bei einem gelungenen Verbindungsaufbau. Zwar funktioniert das auch mit 0800er-Nummern, aber die Zeit übermittelt das ISDN-Netz erst, wenn jemand abnimmt. Hinter TK-Anlagen kann die angezeigte Zeit überdies deutlich von der übertragenen abweichen.

Wer einen Internetzugang eingerichtet hat und gelegentlich online geht, der gelangt dagegen ohne großen Aufwand und zusätzliche Kosten an die genaue Zeit.

Time-Line

Schon früh in der Geschichte des Internet kam die Frage auf, wie man zwischen vernetzten Rechnern die Zeit übermitteln könne. Die ersten Ansätze waren simpel: Ein Server kann über Port 13 (daytime, RFC 867) seine Zeit als ASCII-Klartext zur Verfügung stellen. Alternativ gibt er über Port 37 (time, RFC 868) die Zahl der seit 1.1.1900, 0 Uhr verstrichenen Sekunden als 32-Bit-Binärwert aus. Feiner als eine Sekunde kann man die Zeit mit diesen Services nicht auflösen.

Obendrein sind simple Verfahren wie daytime und time nur innerhalb eines LAN einigermaßen genau, weil dort IP-Pakete mit Millisekundenverzögerung durchlaufen. Beim Zugriff über das Internet mit seinen nicht vorhersagbaren Latenzen kann es dagegen größere und vor allem zeitlich schwankende Abweichungen (Jitter) geben. Schließlich müssen manche Server bei jeder Zeitanfrage über daytime oder time einen neuen Prozess starten: Greifen viele Clients häufig auf diese Dienste zu, steigt die Systemlast übermäßig an. Schon deshalb sollte man diese Funktionen nur in Ausnahmefällen verwenden.

Zwar läuft der time-Zähler erst anno 2036 über, aber die Genauigkeit hängt, genauso wie bei daytime, hauptsächlich von der internen Uhr des Servers ab. Stellt der Administrator diese nicht regelmäßig nach, kann sie im Laufe der Zeit erheblich abweichen. David L. Mills, Chefentwickler von NTP, fand 1988 heraus, dass damals sechzig Prozent von 1158 überprüften Servern mehr als eine Minute von der wahren Zeit abwichen, zehn Prozent sogar mehr als 13 Minuten.

Die Mängel von daytime und time führten zur Entwicklung des hierarchischen Network Time Protocol, kurz NTP (Port 123, RFC 1305 und andere). Darüber können Server untereinander eine gemeinsame Zeit ermitteln. Die Paketlaufzeiten im Netz misst und kompensiert NTP dabei weitgehend. Der NTP-Prozess eines Servers arbeitet zugleich selbst als Uhr, er verlässt sich nicht auf die Systemuhr.