6
Windows-Zeit weicht geringfügig ab
Hallo,
wir haben auf einem Server ein Problem mit der Zeitsynchronisierung, sämtliche Analysen und Fehlerbehebungen haben bisher zu keinem Ergebnis geführt.
Wir haben folgende Konstellation:
Ext. Zeitquelle -> PDC -> DC (Remote Standort) -> Server (Remote Standort)
Die Zeitsynchronisation zwischen folgenden Servern ist in Ordnung:
- externer Zeitquelle und PDC
- PDC und allen DCs an allen Standorten
- Memberserver und den jeweiligen DCs
Es gibt lediglich ein Problem mit der Zeitabweichung zwischen einem Hardwareserver und dem DC an seinem Standort, die Synchronisation ist erfolgreich und es gibt auch keine Hinweise auf Probleme im Log, jedoch weicht die Zeit immer - auch direkt nach dem Resync - zwischen 3 und 7 Sekunden von der Zeit des Zeitgebers ab. Ich habe auch bereits andere Zeitquellen getestet (andere DCs, externe Zeitquelle), auch hier das gleiche Ergebnis.
w32tm /query /status ergibt folgendes Ergebnis:
Sprungindikator: 0(keine Warnung)
Stratum: 5 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.1070099s
Stammabweichung: 7.9243675s
Referenz-ID: 0xC0A80001 (Quell-IP: 192.168.0.1)
Letzte erfolgr. Synchronisierungszeit: 29.01.2018 15:06:26
Quelle: dc.domain.de
Abrufintervall: 10 (1024s)
Hat jemand eine Idee wo man da noch ansetzen kann?
wir haben auf einem Server ein Problem mit der Zeitsynchronisierung, sämtliche Analysen und Fehlerbehebungen haben bisher zu keinem Ergebnis geführt.
Wir haben folgende Konstellation:
Ext. Zeitquelle -> PDC -> DC (Remote Standort) -> Server (Remote Standort)
Die Zeitsynchronisation zwischen folgenden Servern ist in Ordnung:
- externer Zeitquelle und PDC
- PDC und allen DCs an allen Standorten
- Memberserver und den jeweiligen DCs
Es gibt lediglich ein Problem mit der Zeitabweichung zwischen einem Hardwareserver und dem DC an seinem Standort, die Synchronisation ist erfolgreich und es gibt auch keine Hinweise auf Probleme im Log, jedoch weicht die Zeit immer - auch direkt nach dem Resync - zwischen 3 und 7 Sekunden von der Zeit des Zeitgebers ab. Ich habe auch bereits andere Zeitquellen getestet (andere DCs, externe Zeitquelle), auch hier das gleiche Ergebnis.
w32tm /query /status ergibt folgendes Ergebnis:
Sprungindikator: 0(keine Warnung)
Stratum: 5 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.1070099s
Stammabweichung: 7.9243675s
Referenz-ID: 0xC0A80001 (Quell-IP: 192.168.0.1)
Letzte erfolgr. Synchronisierungszeit: 29.01.2018 15:06:26
Quelle: dc.domain.de
Abrufintervall: 10 (1024s)
Hat jemand eine Idee wo man da noch ansetzen kann?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 362744
Url: https://administrator.de/contentid/362744
Printed on: April 25, 2024 at 13:04 o'clock
6 Comments
Latest comment
Hi,
ich kenne Eure Anforderungen dafür nicht und will das deshalb auch gar nicht bewerten.
Aber über 7 Sekunden Abweichung denken wir bei uns nicht nach ...
E.
ich kenne Eure Anforderungen dafür nicht und will das deshalb auch gar nicht bewerten.
Aber über 7 Sekunden Abweichung denken wir bei uns nicht nach ...
E.
Wir haben bei einer Anwendung ein kleineres Problem dadurch, deshalb ist es überhaupt aufgefallen.
Hallo,
Wenn die Zeit so "extrem" driftet, ist es meist der Chip des MoBo, wenn es sich um echte Hardware handelt. War die Drift schon immer so?
Wenn die Zeit so extrem wichtig ist, lass den Server alle x Stunden die Zeit synchronisieren.
BFF
Wenn die Zeit so "extrem" driftet, ist es meist der Chip des MoBo, wenn es sich um echte Hardware handelt. War die Drift schon immer so?
Wenn die Zeit so extrem wichtig ist, lass den Server alle x Stunden die Zeit synchronisieren.
BFF
kann auch sein, daß die Rechner den HighPrecisiontimer Bug haben (in dem Fall wird nicht konstant ein Timer eines dediizierten CPU-Kerns genommen) oder das Energiemanagement hat nen Schlag weg daß dynamische Taktfrequenzen nicht kompensiert werden oder CPU-Overprovisioning bei Überschreitung von 100% Last auf VMware oder HyperV Hosts
Zitat von @BassFishFox:
Wenn die Zeit so "extrem" driftet, ist es meist der Chip des MoBo, wenn es sich um echte Hardware handelt. War die Drift schon immer so?
Leider weiß ich nicht, wielange das Problem bereits besteht. Es handelt sich um echte Hardware und nach Rücksprache mit dem Hersteller, könnte das MainBoard ausgetaucht werden, man glaubt aber nicht hunderprozentig, dass es daran liegt.Wenn die Zeit so "extrem" driftet, ist es meist der Chip des MoBo, wenn es sich um echte Hardware handelt. War die Drift schon immer so?
Wenn die Zeit so extrem wichtig ist, lass den Server alle x Stunden die Zeit synchronisieren
Die Zeit weicht auch direkt nach einem erfolgreichen Resync um aktuell 7 Sekunden ab, daher bekomme ich auch dadurch keine korrekte Zeit.Zitat von @GrueneSosseMitSpeck:
kann auch sein, daß die Rechner den HighPrecisiontimer Bug haben (in dem Fall wird nicht konstant ein Timer eines dediizierten CPU-Kerns genommen) oder das Energiemanagement hat nen Schlag weg daß dynamische Taktfrequenzen nicht kompensiert werden oder CPU-Overprovisioning bei Überschreitung von 100% Last auf VMware oder HyperV Hosts
CPU-Overprovisioning kann ich ausschließen, den Rest erstmal nicht, allerdings würde ich in diesem Fällen nach meinem Verständnis nach einem /resync die richtige Zeit erhalten.kann auch sein, daß die Rechner den HighPrecisiontimer Bug haben (in dem Fall wird nicht konstant ein Timer eines dediizierten CPU-Kerns genommen) oder das Energiemanagement hat nen Schlag weg daß dynamische Taktfrequenzen nicht kompensiert werden oder CPU-Overprovisioning bei Überschreitung von 100% Last auf VMware oder HyperV Hosts
Hallo,
Das mit dem Boardtausch ware eine Alternative. Ebenso eine manuell festgelegte Zeitquelle als Test.
Aktiviere mal das Logging, 7s kommen doch nicht von irgendwie allein.
BFF
Das mit dem Boardtausch ware eine Alternative. Ebenso eine manuell festgelegte Zeitquelle als Test.
Aktiviere mal das Logging, 7s kommen doch nicht von irgendwie allein.
BFF
