13. September 2017

Mit Kithara durch Adressraum und Zeit

"Zeit ist das, was man an der Uhr abliest." – Ganz so einfach, wie Einstein es scherzhaft formulierte, ist es gerade beim Jonglieren mit Systemzeiten und Zeitbasen leider oft nicht, wie die Zeitreise eines unserer Entwickler zeigt.

Bei der Entwicklung unseres PTP Stacks (Precision Time Protocol) reiste dieser aufgrund unterschiedlicher beteiligter Zeitbasen plötzlich in das Jahr 1601; zumindest zeigte dies die Systemzeit des Rechners an. Um der harschen Welt des 17. Jahrhunderts zu entkommen, musste der Entwickler jedoch den Fluxkompensator zunächst auf 1985 stellen, um Windows in die Lage zu versetzen, von dort überhaupt erst einmal Kontakt mit dem NTP (Network Time Protocol) Zeitserver aufnehmen zu können.

Zurück in der Gegenwart wurden dann zu weiteren Testzwecken ein paar Modifikationen an der Entwicklungsumgebung vorgenommen. Das neue Set-up ermöglichte eine Zeitschleife verteilt über 2 Rechner, gekoppelt mit einem EtherCAT-Netzwerk. Plötzlich beschleunigte der Zeitgeber jedoch und der Entwickler reiste diesmal ungewollt in Richtung Zukunft. Irgendwann um das Jahr 6000 brachen wir den Kontakt vorsichtshalber ab.

An diesem kleinen Ausflug kann man erkennen, wie komplex beim systemnahen Programmieren die Behandlung der Systemzeit sein kann, gerade wenn verschiedene Zeitbasen involviert sind. Allein der unterschiedliche Umgang mit den berüchtigten Schaltsekunden bereitet der IT seit jeher Kopfzerbrechen:

Was hat es damit auf sich? Nachdem ab dem Jahre 1958 Atomuhren weltweit die Kontrolle über die genaue Zeit übernahmen, begann man auch, die stetig langsamer werdende Erdrotation mit einzuberechnen, indem gelegentlich (ca. alle 18 Monate jeweils zum 1. Januar oder zum 1. Juli) eine zusätzliche Sekunde hinzugefügt wird. Die koordinierte Weltzeit UTC (Universal Time Coordinated) berücksichtigt diese Schaltsekunden, von denen mittlerweile bereits 37 zusammengekommen sind. Was im normalen Leben kaum Einfluss nimmt, kann für Rechnerprozesse jedoch zu erheblichen Komplikationen führen, wie die zahlreichen Server- und GPS-Probleme 2012 und 2015 gezeigt haben. Im Moment, in dem die Schaltsekunde eingefügt wird, müsste in UTC streng genommen zwischen einer A- und B-Sekunde unterschieden werden. Zeitkritische bzw. fortlaufende Systeme sollten jedoch, unabhängig von UTC, stattdessen stets auf einen frei laufenden Zeitgeber zurückgreifen, um eventuelle Deadlocks zu vermeiden. Der Kithara-PTP-Stack stellt hierfür die genaue Maschinenzeit in 100-Nanosekunden-Auflösung zur Verfügung.

Trotz aller Zeitreisen, die unsere Programmierer während der Entwicklung "unternommen" haben, wird sich die Anwendung des neuen PTP Module für Benutzer recht bedienungsfreundlich gestalten. Sie müssen also nicht fürchten, aus Versehen ein Zeitparadoxon auszulösen.