NTP Probleme

NTP Probleme

Nachdem 2 Funkuhren von mir auseinanderliefen wollte ich mithilfe meines stets per NTP auf dem korrekten Stand gehaltenen Rechners herausfinden, welche Uhr denn nun richtig läuft. Dabei stellte ich erstaunt fest, daß mein Rechner eine 3. Uhrzeit aufwies.

Per NTP sollten bzw. können sich PCs mit hoher Genauigkeit (im Millisekunden-Bereich, was fast immer vollkommen ausreichend ist) auf die aktuelle Zeit ausrichten. Dabei wird eine Anfrage an einen Rechner im Internet gestellt (z. B. die Zeitserver der Physikalisch-Technischen Bundesanstalt in Braunschweig, die u. a. auch Atomuhren betreibt und das Radiosignal aussendet, durch das Funkuhren synchronisiert werden), der eine genaue Zeit zurückliefert. Über das Rückrechnen von Latenzen, die durch die Kommunikation entstehen, erhalten wir so eine aktuelle Zeit, die sehr genau ist.

Hier habe ich den Zeitdienst bereits gestoppt, da er ohnehin nicht funktioniert hat

Übrigens ist die Grenze der Genauigkeit oft eher der Windows-/PC-eigene Zeitgeber, der oft nur mit einer Genauigkeit von 16ms läuft. Wir können hier also zwangsweise keine höhere Genauigkeit erwarten als es der Windows Zeitgeber ermöglicht. Ein Abgleich dient somit auch nur dem Zweck, das Auseinanderlaufen der lokalen Uhr (ein Vorgang, der oft nur über Wochen sichtbar ist) auszugleichen.

Probleme mit Bordmitteln

Nun war bei mir ein NTP Server eingerichtet, ein automatischer Abgleich konfiguriert, eine Internetverbindung vorhanden und – was mich dann verdutzt hat – beim Aufruf der entsprechenden Funktion erhielt ich sogar die Nachricht, daß der Abgleich erfolgreich gelaufen war. Nur.. die PC Uhr wich 15 Sekunden von der richtig laufenden Uhr ab. In dieser Ungenauigkeit sollte ein Abgleich nicht enden. Also fing ich an, das Problem zu suchen und stellte zunächst fest, daß dies wohl ein recht beliebtes Problem ist (viele Leute haben dieses Problem) und daß es keine allgemeine Lösung gibt, nur in Einzelfällen berichteten Leute von einer Lösung in ihrem speziellen Fall.

Abgleich aus der Kommandozeile

Um die wenig aussagekräftigen Fehlermeldungen in der GUI etwas aufzubohren ging ich in die Kommandozeile. Der erste Befehl, der in den Sinn kommt, stößt eine automatische Neusynchronisation an.

Ohne Administrator-Rechte erhalte ich direkt eine Fehlermeldung bzgl. fehlender Rechte.

C:Usersareiff>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Folgender Fehler ist aufgetreten: Zugriff verweigert (0x80070005)

Mit Admin-Rechten ändert sich dann zumindest der Fehler.

C:Windowssystem32>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.

Prinzipiell erreichbar ist der Zeitserver, wie ich mit einem Ping teste.

C:Usersareiff>ping ptbtime1.ptb.de
 
Ping wird ausgeführt für ptbtime1.ptb.de [192.53.103.108] mit 32 Bytes Daten:
Antwort von 192.53.103.108: Bytes=32 Zeit=49ms TTL=52
Antwort von 192.53.103.108: Bytes=32 Zeit=40ms TTL=52
Antwort von 192.53.103.108: Bytes=32 Zeit=53ms TTL=52
Antwort von 192.53.103.108: Bytes=32 Zeit=43ms TTL=52
 
Ping-Statistik für 192.53.103.108:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 40ms, Maximum = 53ms, Mittelwert = 46ms

Ein Neusetzen der Konfiguration und erneutes Ausführen des Befehls blieb erfolglos.

C:Windowssystem32>w32tm /config /update /syncfromflags:MANUAL /manualpeerlist:
"ptbtime1.ptb time.windows.com.de" /reliable:YES
Der Befehl wurde erfolgreich ausgeführt.
 
C:Windowssystem32>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.
 
C:Windowssystem32>w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 1 (Primärreferenz - synchron. über Funkuhr)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 10.0000000s
Referenz-ID: 0x4C4F434C (Quellname:  "LOCL")
Letzte erfolgr. Synchronisierungszeit: 08.04.2012 19:52:22
Quelle: Local CMOS Clock
Abrufintervall: 10 (1024s)

Zunächst werden die Zeitserver neu konfiguriert, anschließend wird ein Sync versucht, und am Ende gucken wir, wo unsere Zeitdaten herkamen: aus der lokalen CMOS Clock. Die geht zwangsweise ungenau.

Auch ein Untersuchen der Registry sowie ein genaueres Stellen der aktuellen Uhrzeit (bei zu großer Abweichung – allerdings eher im Minuten- oder Stunden-Bereich führt ebenfalls zu einem erfolglosen Abgleich) blieben erfolglos.

Der Workaround

Time Watch mit tollen Features wie einem Mondkalender, Feiertagen, und.. einer funktionierenden NTP-Synchronisation

Nachdem ich längere Zeit – vergebens – nach einer Lösung gesucht hatte und auch immer mehr Informationen fand über Leute, die ähnliche Probleme hatten und sie nicht fixen konnten, entschloß ich mich, ein separates Programm zu installieren.

Nach den Problemen, die der hauseigene NTP-Abgleich mit sich bringt laufen diese erstaunlich geschmeidig, um genauer zu sein, versteht man gar nicht mehr, warum der Microsoft-Dienst so schlecht und fehlerträchtig laufen konnte.

Benutzt habe ich Time Watch 4.0. Damit kann ich mich nicht nur vollkommen problemlos per NTP synchronisieren, sondern ich bekomme sogar aktuelle Feiertage, Mondkalender und andere ungemein nützliche Informationen angezeigt.

Da die CMOS Uhr normalerweise recht genau geht und merkbare Abweichungen nur in einem Zeitraum von Wochen bis Monaten auftreten, habe ich das Programm nicht in den Autostart genommen und werde es bei Bedarf manuell starten. Das schont die Ressourcen meines Rechners.

Übrigens.. per Default synchronisiert das Programm alle Stunde und findet auch immer Abweichungen im Bereich von 10ms. Das ist natürlich irreführend: die Genauigkeit des Systems ist ja meistens nur 16ms, alles darunter können wir (und sollte das Programm) ignorieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.