Funktionsweise des Meinberg-Zeitservice

Der Meinberg-Zeitservice (mbgadjtm.exe) wird als Teil des Meinberg-Treiberpakets für Windows mitgeliefert, um die Windows-Systemzeit mit der Zeit einer Meinberg-PCI-Karte, einer Meinberg-USB-Uhr oder auch einer externen Meinberg-Uhr zu synchronisieren. Wenn der Service aktiviert ist, läuft er im Hintergrund, führt periodisch Zeitvergleiche durch, und korrigiert die Windows-Systemzeit, falls erforderlich.

Das ebenfalls mitgelieferte Monitorprogramm (mbgmon.exe) kann verwendet werden, um den Zeitservice sowie die installierte Funkuhr zu konfigurieren, falls nötig, und den Status zu kontrollieren. In den meisten Fällen sollte die Standard-Konfiguration für eine zuverlässige Funktionsweise angemessen sein, so dass Änderungen der Service-Konfiguration nicht nötig sein sollten.

Nach der Installation des Treiberprogramms muss der Zeitservice einmalig erst aktiviert werden, nachdem die ordnungsgemäße Zeit der Funkuhr überprüft wurde.

Erst nachdem die installierte Funkuhr mindestens einmal nach dem Einschalten synchron zum Sender war, beginnt der Zeitservice mit der Nachführung der Systemzeit.

Dadurch soll verhindert werden, dass die Systemzeit falsch gesetzt wird, wenn das System z.B. lange ausgeschaltet war und dadurch die Zeit der Funkuhr direkt nach dem Einschalten nicht mehr genau ist.

Die Funkuhr gibt einen entsprechenden Synchron-Status zusammen mit ihrer aktuellen Zeit aus. Nachdem die Uhr mindestens einmal mit ihrer Zeitquelle synchronisiert war, verwendet der Zeitservice die Zeit der Funkuhr auch dann, wenn die Funkuhr danach zeitweise Empfangsprobleme hat und frei auf Quarzbasis läuft.

Die Windows-Systemzeit läuft intern auf UTC (Weltzeit, früher auch GMT genannt), und die meisten Programme zur Zeitsynchronisierung arbeiten generell so, dass eine externe Referenzzeit immer erst auf UTC zurückgerechnet wird: bei einer DCF77-Funkuhr werden bei Sommerzeit 2 Stunden abgezogen, um UTC zu erhalten, bei Standardzeit entsprechend nur 1 Stunde. Diese UTC-Zeit wird dann mit der UTC-Systemzeit des Rechners verglichen, und die UTC-Systemzeit des Rechners wird nachgeführt, falls erforderlich, um diese Zeitdifferenz so gering wie möglich zu halten.

Zu den Programmen, die auf diese Weise arbeiten, gehören neben dem Meinberg Zeitservice auch der NTP-Dienst für Windows (ntpd.exe), sowie der bei Windows mitgelieferte Dienst “Windows-Zeitgeber” (w32time.exe).

Aufgrund der oben beschriebenen Funktionsweise hat der Sommerzeit-Status einer Funkuhr keinen Einfluß darauf, welche Ortszeit in Windows angezeigt wird, und ebensowenig wird von der Funkuhr abgeleitet, ob und wann in Windows eine Sommerzeit-Umschaltung stattfindet.

Stattdessen sind die Regeln für die Berechnung der aktuellen Ortszeit aus der aktuellen Systemzeit für jede in Windows auswählbare Zeitzone in der Windows-Registry hinterlegt. Wenn sich die Regeln zur Sommerzeitumschaltung durch politische Entscheidungen ändern, müssen diese Regeln in der Registry entsprechend aktualisiert werden, was normalerweise durch Windows-Updates geschieht, die durch Microsoft bereitgestellt werden.

Aus Sicht der Zeitsynchronisierung tritt also kein Zeitsprung zu Beginn oder Ende der Sommerzeit auf, denn die Windows-Systemzeit wird nicht umgestellt. Stattdessen wird lediglich die Berechnung der Ortszeit aus der Systemzeit angepaßt und die Ortszeit entsprechend dargestellt.

Windows stellt jeglichen Programmen unterschiedliche Funktionen zur Verfügung, die entweder die aktuelle UTC-Systemzeit oder aber die aktuelle Ortszeit entsprechend der gewählten Zeitzonen-Einstellung zurückliefern.

D.h., wenn die zugrundeliegende Windows-Systemzeit korrekt ist und die in der Registry hinterlegten Zeitzonen-Einstellungen stimmen, findet die Umstellung der angezeigten Ortszeit in Windows immer exakt zum richtigen Zeitpunkt statt.

Siehe auch die Meinberg Whitepapers unter

• https://www.meinberg.de/german/info/#whitepaper

Speziell die Kapitel 4.4, 4.6 und 4.7 in

• “Computer Time Synchronization Concepts”
  https://www.meinberg.de/download/burnicki/Computer%20Time%20Synchronization%20Concepts%20-%202014-04-29.pdf

Das Monitorprogramm mbgmon.exe zeigt im Tab “Windows-Zeitzone” die aktuellen Einstellungen der gewählten Windows-Zeitzone an. Dieses Feature wurde ins Monitorprogramm eingebaut, weil es in älteren Windows-Versionen keine Möglichkeit gab, Details der gewählten Einstellung anzusehen und die aktuell wirksamen Schaltzeiten für Beginn und Ende der Sommerzeit zu überprüfen.

Wenn der Zeitservice aktiv ist, werden im Tab “Zeitvergleich” des Monitorprogramms die “Rechner-Systemzeit”, die “Referenzzeit” (Funkuhrzeit) sowie die errechnete “Zeitdifferenz” angezeigt. Diese Werte werden nach jedem Zeitvergleich aktualisiert. Der Zeitvergleich erfolgt zwar etwa sekündlich, aber normalerweise nicht exakt zum zum Sekundenwechsel, sondern irgendwann mitten in der Sekunde. Die Zeiten werden deshalb mit 100stel Sekunden Auflösung angezeigt, die “Zeitdifferenz” unter Umständen mit noch höherer Auflösung.

Wenn die Differenz zwischen der Windows-Systemzeit und der von der Funkuhr gelesenen Referenzzeit kleiner ist als der sognannte “Sync. Radius” (default 1 s, siehe Tab “Zeitservice” im Monitorprogramm), wird die Systemzeit durch leichte Beschleunigung oder Verlangsamung “weich” nachgeführt, so dass andere Programme diese Korrekturen normalerweise gar nicht bemerken und im Dauerbetrieb gar nicht erst eine größere Zeitabweichung entsteht.

Die aktuell angebrachte weiche Zeitkorrektur wird im Feld Status des Zeitservice“ als Wert “Zeitnachführung:” angezeigt.

Nur wenn die Zeitdifferenz den “Sync. Radius” überschreitet, wird die Windows-Systemzeit hart gesetzt. Das geschieht normalerweise nur einmalig beim Start des Zeitservice bzw. des Rechners.

Nur wenn die Systemzeit hart gesetzt wurde, wird im unteren Teil des Tabs “Zeitvergleich” angezeigt, wann das geschehen ist, und wie groß die Zeitdifferenz war, die korrigiert wurde. Wenn keine große Zeitabweichung auftritt und deshalb kein hartes Setzen der Systemzeit erforderlich ist, wird an dieser Stelle nichts angezeigt.

Neben fehlerhaften Systemkonfigurationen, wo z.B. noch weitere Programme die Windows-Systemzeit verstellen, gibt es eigentlich nur 2 Möglichkeiten, wie eine größere Zeitdifferenz entstehen kann:

1.) Unmittelbar nach einem Neustart des Rechners existiert ein Zeitunterschied zwischen der Funkuhrzeit und der Systemzeit des Rechners. Die Funkuhr ist noch nicht synchron, daher ist nicht bekannt, ob die Funkuhr oder die Systemzeit “richtiger” ist. Der Zeitservice wartet, bis die Funkuhr synchron wird und damit die genaue Zeit hat, und beginnt erst dann mit der Synchronisierung der Systemzeit.

2.) Die Funkuhr war bereits einmal synchron, so dass der Zeitservice die Systemzeit mit der Funkuhrzeit nachregelt, auch wenn sie danach keinen Empfang mehr hat und in den Freilauf geht. Während des Freilaufs der Funkuhr driftet ihre Zeit natürlich, und wenn die Uhr sehr lange im Freilauf bleibt, kann die Zeit schon signifikant wegdriften. Wenn dann plötzlich die Funkuhr wieder synchron wird, springt ihre Zeit wieder auf den genauen Wert, und es besteht plötzlich ein Zeitunterschied zwischen der Funkuhrzeit und der Systemzeit, die ja “mitgedriftet” war.

In beiden Fällen “sieht” der Zeitservice eine Zeitdifferenz, die kompensiert werden muss, indem die Systemzeit korrigiert wird.

Wenn die zu korrigierende Zeitdifferenz größer ist als der “Sync. Radius”, wird die Systemzeit nicht weich nachgeführt, sondern einmalig hart gesetzt. Wenn die Abweiching z.B. 7 Minuten beträgt, wird die Systemzeit um 7 Minuten verstellt. Als Folge können eventuell andere Programme, die zu Minutenwechseln aktiv werden, die übersprungenen Minutenwechsel verpassen.

Abhilfe kann man schaffen, indem man den “Sync. Radius” entsprechend hoch setzt, dann wird die Systemzeit auch bei größeren Abweichungen weich nachgeführt, was natürlich entsprechend lange dauern kann.

Hinweis: Im Monitorprogramm älterer Treiberversionen können nur Werte bis 99 s eingegeben kann. Das ist eine Einschränkung im Monitorprogramm. Wenn das Monitorprogramm aktualisiert wird, können Werte bis 99999 s eingeben werden.

In neueren Treiberversion ab dkwin-3.08 ist es möglich, das harte Setzen der Zeit komplett zu deaktivieren, indem man den “Sync. Radius” auf 0 s setzt. Bei früheren Treiberversionen sollte das jedoch nicht gemacht werden, da der Zeitservice das nicht unterstützten und bei einem “Sync. Radius” von 0 s alle paar Sekunden die Systemzeit hart setzen würde, da ja die Zeitabweichung immer etwas größer oder kleiner ist als 0, aber nie genau 0.

Die aktuelle Treiberversion gibt es auf dem Meinberg-Webserver zum Download:

• https://www.meinberg.de/german/sw/#win

Wenn die Zeitsynchronisierung nicht funktioniert, wie erwartet, sind die nachfolgenden Information vielleicht hilfreich, den Grund dafür herauszufinden.

Wenn zusätzliche Programme ebenfalls versuchen, die Windows-Systemzeit zu verstellen, kann es vorkommen, dass die Systemzeit instabil wird, d.h., häufig abwechselnd viel zu schnell oder viel zu langsam geht, wenn unterschiedliche Programme unterschiedliche Zeitkorrekturen vornehmen, oder dass sogar unerwartete Zeitsprünge auftreten.

Verantwortlich sein dafür kann z.B. der Dienst w32time der zyklisch versucht, die Systemzeit zu korrigieren, oder auch der NTP-Dienst (ntpd), wenn dieser installiert ist und falsch konfiguriert wurde, sowie jede andere Software zur Zeitsynchronisierung, die parallel zum Meinberg Zeitservice läuft, oder zyklisch gestartet wird.

Dabei muss man unterscheiden, ob auch ein anderes Programm die Zeit weich nachführt, oder ob ein anderes Programm die Zeit manchmal hart setzt.

Wenn die Zeitdifferenz innerhalb des “Sync Radius” ist, bringt der Meinberg-Zeitservice nur kleine Korrekturen an. Der Standardwert, mit dem die Windows-Systemzeit läuft, nennt sich “Tick-Wert” und hat (je nach Windows-Version) z.B. den Standard-Wert 156000. Wenn der Zeitservice feststellt, dass die Windows-Zeit etwas voraus ist, oder generell zu schnell geht, verringert der Service diesen Tick-Wert und merkt sich, welchen Wert er eingestellt hat, z.B. 155946.

Beim nächsten Zeitvergleich etwa 1 s später prüft der Meinberg-Zeitservice, ob der aktuelle Tick-Wert noch der gleiche ist, den er selbst vorher eingestellt hat. Wenn das nicht der Fall ist, hat ein anderes Programm in der Zwischenzeit ebenfalls eine “weiche” Korrektur vorgenommen. Wenn dies erkannt wird, wird im Monitorprogramm eine Meldung angezeigt, die aussagt, dass die Systemzeit von einem anderen Programm verändert wurde, und es wird ein Log-Eintrag im Windows-Anwendungsprotokoll erstellt, der etwa so lautet:

Der Wert für die Nachführung der Systemzeit wurde von einem anderen Programm geändert: 155946 → 156001.

Hier im Beispiel hat ein anderes Programm die Zeitkorrektur des Meinberg-Zeitservice nahezu rückgängig gemacht. Dadurch wird natürlich eine optimale Zeitnachführung beeinträchtigt.

Im Normalfall setzt der Meinberg-Zeitservice nur einmalig die Systemzeit hart, wenn dies nach dem Start des Service erforderlich ist. Wie schon oben beschrieben, werden Informationen dazu im Monitorprogramm angezeigt.

Der Meinberg-Zeitservice führt seine Zeitvergleiche zwar etwa sekündlich durch, jedoch nicht genau zum Sekundenwechsel, sondern irgendwann mitten in der Sekunde. Wenn der Service dann entscheidet, dass die Systemzeit gesetzt werden muss, weil die Differenz größer ist als der “Sync. Radius”, wird die Systemzeit auch entsprechend zu solch einem Zeitpunkt gesetzt, und eine Log-Meldung in der Anwendungs-Ereignisanzeige kann z.B. lauten:

Die Systemzeit des PCs wird auf 2017-07-13 08:10:10.690 (UTC+02:00h) gesetzt.

und in der System-Ereignisanzeige entsprechend:

Die Systemzeit wurde von 2017-07-13T06:10:03.007300700Z in 2017-07-13T06:10:10.690000000Z geändert.

Man sieht also, dass die Systemzeit durch den Meinberg-Zeitservice nicht auf “glatte” Sekunden gesetzt wird, sondern auf einen “krummen” Wert, je nachdem, wann innerhalb der Sekunde der Zeitvergleich stattfand, der zum Setzen der Zeit führte.

Einträge im der System-Ereignisanzeige, wo die Zeit auf eine “glatte” Sekunde gesetzt wird, wie z.B.

Die Systemzeit wurde von 2017-07-13T06:10:07.683199400Z in 2017-07-13T06:10:00.000000000Z geändert.

stammen dagegen mit hoher Wahrscheinlichkeit von einem anderen Programm, das einfach die Zeit mit Stunden-Minuten-Sekunden gesetzt hat, und es gibt sicherlich keine entsprechenden Enträge vom Meinberg-Zeitservice dazu in der Anwendungs-Ereignisanzeige.

Wenn ein anderes Programm die Systemzeit so verstellt hat, dass sie außerhalb des “Sync. Radius” liegt, und die Zeitdifferenz über mehrere Sekunden bestehen bleibt (Parameter “Anzahl der korrekten Telegramme” im Tab “Zeitservice” des Monitorprogramms, default 3), stellt der Meinberg-Zeitservice die Zeit wieder zurück. Dabei wird dann auch die Anzeige im Monitorprogramm aktualisiert, wie oben beschrieben, und entsprechende Log-Einträge erzeugt.

Wenn plötzlich bei einem Zeitvergleich eine größere Differenz zwischen der Windows-Systemzeit und der Referenzzeit (Funkuhrzeit) auftritt, könnte der Meinberg-Zeitservice normalerweise nicht wissen, ob die Systemzeit oder die Funkuhrzeit aus irgendeinem Grund gesprungen ist. Windows stellt jedoch mit der Funktion QueryPerformanceCounter (QPC) eine Funktion bereit, mit der man ebenfalls Zeitdifferenzen messen kann, und mit Hilfe dieser Information kann man herausfinden, ob die Systemzeit oder die Referenzzeit einen Sprung gemacht hat.

Der Zeitservice merkt sich bei jedem Zeitvergleich die Funkuhrzeit, die Systemzeit, und den QPC-Wert. Der nächste Zeitvergleich findet etwa 1 s später statt. Das is normalerweise weder exakt eine Sekunde später, noch ist es exakt zu einem Sekundenwechsel, sondern einfach z.B. 0.9 s, 1 s oder 1.1 s nach dem letzten Zeitvergleich, je nachdem, wann Windows den Zeitservice wieder “aufweckt”.

Das genaue Zeitintervall seit dem letzten Zeitvergleich ist unerheblich, denn wenn die Zeitdifferenz vorher klein war, sollten 1.1 s später sowohl die Systemzeit als auch die Referenzzeit als auch der QPC-Wert um 1.1 s fortgeschritten sein, so dass die Differenzen zwischen den einzelnen Zeiten nicht wesentlich größer sind als vorher.

Wenn jedoch nur 2 Zeitdifferenzen etwa gleich groß sind, aber die 3. Zeitdifferenz signifikant davon abweicht, handelt es sich um eine Unstimmigkeit, die in der Anwendungs-Ereignisanzeige protokolliert wird.

Es wurde eine Unstimmigkeit im Zeitverlauf festgestellt:
Reference time [hns]: 131443998086900479 - 131443998076898949 = 10001530
System time [hns]: 131443998010061679 - 131443998076892635 = -66830956
Delta diff [hns]: -76832486
PerfCounter: 1033430997 - 1023429964 = 10001032

Zeit-Intervall Funkuhr (“Reference Time”): 10001530 hns, also  1.0001530 s
System-Zeitintervall (“System time”):     -66830956 hns, also -6.6830956 s
QPC-Zeitintervall (“PerfCounter”):         10001032 hns, also  1.0001032 s

Hier im Beispiel ist also sowohl die Funkuhrzeit als auch der QPC-Wert seit dem letzten Zeitvergleich um ziemlich genau 1 s fortgeschritten. Die Systemzeit allerdings ist stattdessen mehr als 6 s zurückgegangen, statt wie erwartet um 1 s weiter. Folglich wurde hier die Systemzeit um etwa 7 Sekunden zurückgestellt.

Wenn die Funkuhr nach längerem Freilauf wieder aufsynchronisiert und deshalb die Funkuhrzeit springt, wird kein solcher Log-Eintrag gemacht. Stattdessen wird die Statusänderung Freilauf/Synchron protokolliert.

Wenn in der System-Ereignisanzeige aktuelle Log-Einträge mit Text “Die Systemzeit wurde … geändert.” vorhanden sind, kann man über den jeweiligen Log-Eintrag den Namen des Prozesses herausfinden, der die Zeit gestellt hat. Dazu klickt man auf den “Details”-Tab des Ereignisses, und unter System / Execution / [Process ID] wird die numerische Prozess-ID angezeigt.

In einer Powershell-Konsole kann man dann den Befehl get-process eingeben und bekommt eine Tabelle aller laufenden Prozesse mit den Spalten ID und Name aufgelistet. Dort kann man nach dem Prozess mit der numerischen ID suchen und erhält dann den Namen des entsprechenden Programms.

Das funktioniert natürlich nur, wenn der entsprechende Prozess noch läuft. Also nicht, wenn ein Service inzwischen neu gestartet wurde und eine andere Process ID bekommen hat, oder ein Kommando wie “time” nur einmalig ausgeführt und dann wieder beendet wurde.

— Martin Burnicki martin.burnicki@meinberg.de 2018-12-11