PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: NetTime: Einfache Zeitsynchronisation


Leonidas
2018-01-01, 13:58:01
Link zum Blogeintrag:
https://www.3dcenter.org/blog/leonidas/nettime-einfache-zeitsynchronisation

aufkrawall
2018-01-01, 14:44:01
Windows kann selber die Uhr stellen und das zeitig über die Aufgabenplanung ausführen, das ist absolute Grundfunktionalität von OSen.

Monger
2018-01-01, 16:09:41
Finde das genannte Problem auch n bissl exotisch. Wo genau hat denn Windows Probleme mit Zeitstempeln? Der Artikel suggeriert ja dass die Netzwerkkonnektivität ohne korrekte Uhr nicht zustande kommt. Da würde ich gerne mehr Infos sehen, bevor so ein obskurer Workaround empfohlen wird.

Leonidas
2018-01-02, 03:40:40
Im konkreten Fall funktionierte selbst die direkte Anweisung an Windows, nach OS-Start die korrekte Zeit einzuholen, überhaupt nicht. Nur der manuelle Weg funktionierte.

Hängt möglicherweise an dem komplett abweichenden Datum -> das System startet nach Abhängen vom Strom am 4.1.1980.

BTB
2018-01-02, 07:28:03
Viel nerviger ist das mein Atom Tablet im Standby die Uhr wohl nicht richtig mitlaufen lässt. Das kann ich mit so einem Tool nur durch ständigen Sync beheben. Toll wäre eine Option zusätzlich nach Neustart auch nach dem Aufwachen.

Corny
2018-01-02, 09:05:50
Im konkreten Fall funktionierte selbst die direkte Anweisung an Windows, nach OS-Start die korrekte Zeit einzuholen, überhaupt nicht. Nur der manuelle Weg funktionierte.

Hängt möglicherweise an dem komplett abweichenden Datum -> das System startet nach Abhängen vom Strom am 4.1.1980.

Die Erfahrung habe ich auch bereits gemacht, wenn das eingestellte Datum zu weit vom tatsächlichen entfernt ist, macht Windows keine Synchronisation.

Brechreiz
2018-01-02, 18:49:39
@ Leonidas: Da hätte es kein Tool gebraucht:

https://support.microsoft.com/en-us/help/884776/how-to-configure-the-windows-time-service-against-a-large-time-offset

regedit: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

MaxNegPhaseCorrection : 0xFFFFFFFF (Hex)
The default value of these two registry entries is 0xFFFFFFFF. This default value means "Accept any time change."

War wohl so noch bei XP und wurde ab Vista geändert.

Dann als Zeit-Quelle: 0.nettime.pool.ntp.org. Funzt mit Boardmitteln.

Leonidas
2018-01-02, 18:52:04
Hochinteressant, könnte die Ursache des Problems gewesen sein.

Brechreiz
2018-01-02, 19:00:56
Aber gut zu wissen das Nettime noch ein Update bekommen hat. Dachte mir das ist zu Windows 98 Zeiten eingeschlagen.

lumines
2018-01-02, 19:03:16
Kann es sein, dass Windows nicht mit kaputten oder fehlenden RTCs klarkommt? Andere System speichern dafür die letzte gültige Zeit vor dem Shutdown oder in regelmäßigen Abständigen irgendwo in eine Datei, was ja auch irgendwie Sinn ergibt.

Der Zeitsynchronisation unter Windows auf die Sprünge zu helfen ist aber echt nicht so ganz trivial. Kann man natürlich über die Aufgabenplanung machen, aber so einfach fand ich das jetzt nicht. Das UI dafür ist echt nicht so optimal und hat einigen Stellen auch Übersetzungsfehler. "Any" wird da bei dem Trigger für Netzwerkverbindungen mit "Alle" übersetzt.

Dass es mit so großen Sprüngen wie in Leonidas' Fall standardmäßig nicht klarkommt, habe ich so auch nicht in der Doku gesehen. So etwas sollte eigentlich fett markiert sein. Eigentlich sollte ein großer Sprung für die erste Synchronisation an einem Desktop auch immer möglich sein. Jedenfalls handhaben das andere (S)NTP-Clients wie Chrony oder OpenNTPD AFAIK genau so. Vielleicht ist das nicht so die reine NTP-Lehre, aber die Alternative ist ja auch nicht wirklich praktikabel.

Leonidas
2018-01-14, 06:28:41
Update:

Funktioniert leider bei mir generell nicht mit der Aufgabenplanung, auch nach Änderung des von Brechreiz genannten Parameters. Selbst das manuelle Starten der Aufgabe bringt nichts hervor, trotz schon geändertem Timeserver. Ich muß daher bei "NetTime" bleiben.

Liszca
2018-01-31, 22:39:42
Im konkreten Fall funktionierte selbst die direkte Anweisung an Windows, nach OS-Start die korrekte Zeit einzuholen, überhaupt nicht. Nur der manuelle Weg funktionierte.

Hängt möglicherweise an dem komplett abweichenden Datum -> das System startet nach Abhängen vom Strom am 4.1.1980.

Eigentlich sollte ein DHCP Server das vernünftig lösen können ohne diese Notlösung.