Genauigkeit von Funkuhren und NTP
-
scrontch schrieb:
SeppJ schrieb:
[...] ist halt die Frage wem du mehr vetraust: Dem zentralen Sender für ganz Europa oder den Zeitserver den du gewählt hast (Microsoft Server in Redmond?
). Der Lichtgeschwindigkeit oder dem NTP-Protokoll. Also ich würde auf die Funkuhr setzen.Naja, eingentlich sollte es bei NTP eben egal sein wo der Zeitserver steht, da der konstante Anteil der Verzögerung eben rausgerechnet wird.
Ich hatte eher an zufällige Schwankungen durch den langen Weg gedacht. Aber da ich gerade dabei bin, meinen scheinbaren IQ mittels Wikipedia um 30 Punkte zu heben, kann ich auch dies als Fehlerquelle ausschließen. Ich wusste bisher nicht, dass NTP so gut ist, dass es sogar damit zurecht kommt.
-
Zudem sind FAT-Dateisysteme (Ich weiß jetzt nicht genau welche) nur 2-Sekunden genau.
-
anonymous
schrieb:Zudem sind FAT-Dateisysteme (Ich weiß jetzt nicht genau welche) nur 2-Sekunden genau.
-
scrontch schrieb:
Ermutige ihn doch nicht auch noch! Oder kommt es dir vor, als wollte er ernsthaft etwas zum Thema beitragen und nicht nur provozieren?
-
Kannst Du sicher stellen, dass sich die Funkuhr überhaupt synchronisiert hat? Ab einer bestimmten (zu tiefen) Batteriespannung greifen bestimmte Uhrwerke das DCF77-Signal nicht mehr ab und laufen als 'normale' Quarzuhr weiter. Weiterhin ist der Empfang innerhalb von Gebäuden meist recht schlecht und kann die Synchronisation blockieren.
-
Ich habe direkt nach einer Synchronisation beider Geräte verglichen. Die Funkuhr synchronisiert jede Stunde, bei Windows habe ich es manuell syncen lassen.
Nun habe ich mir noch ein paar andere NTP Server rausgesucht und gemerkt, dass die auch alle bis zu zwei Sekunden voneinander abweichen. Also ist wohl doch die Funkuhr genauer, es sei denn man findet einen NTP Server, der wirklich genau läuft. Schade eigentlich, das Protokoll hat ja durchaus Potential...
-
Die Windows-Implementierung von NTP ist nicht genauer: http://support.microsoft.com/kb/939322
"The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs"
-
ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de, sind die Zeitserver welche die Zeit von den Atomuhren abnehmen, die auch für das Funksignal zuständig sind. Vielleicht mal damit probieren.
-
SeppJ schrieb:
Ermutige ihn doch nicht auch noch! Oder kommt es dir vor, als wollte er ernsthaft etwas zum Thema beitragen und nicht nur provozieren?
Ich hatte doch kein Wort gesagt!
Nur meine emotionalen Reaktionen beim lesen seines Posts protokolliert.
-
TheToast schrieb:
ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de, sind die Zeitserver welche die Zeit von den Atomuhren abnehmen, die auch für das Funksignal zuständig sind. Vielleicht mal damit probieren.
Jo, und dann auch mal mit einer "full-featured NTP solution" (Linux/ntpd??) vergleichen. Wäre wirklich mal interessant.
-
SeppJ schrieb:
scrontch schrieb:
Ermutige ihn doch nicht auch noch! Oder kommt es dir vor, als wollte er ernsthaft etwas zum Thema beitragen und nicht nur provozieren?
Vorallendingen einfach mal die Fresse halten wenn man keine Ahnung hat. Oder glaubst Du ich habe das einfach so behauptet ohne es zu wissen? Bei FAT16 weiß ich nämlich das es so ist. Das zeigt mal wieder wie jämmerlich dumm hier welche sind, meinten sie wüssten es und die anderen haben kein Plan. Aber sie selber haben eben nicht recht mit dem was sie da von sich geben.
-
und wenn du uns jetzt noch erklärst, was das Dateisystem bei der ganzen Sache zu tun hat, nimmt dich vll mal jemand für voll
-
zwutz schrieb:
und wenn du uns jetzt noch erklärst, was das Dateisystem bei der ganzen Sache zu tun hat, nimmt dich vll mal jemand für voll
Ist doch eigentlich offensichtlich. Logs wie Erstellungsdatum oder Datum der letzen Änderung, einer Datei / eines Ordner werden bei FAT-Dateisystem eben ins Dateisystem geschrieben. Also nach der Uhrzeit und dem Datum des Computers.
Da jetzt das Drama um eine 1 Sekunde Unstimmigkeit betraf, wollte ich nur mal so nebenbei erwähnen, dass man das bei FAT-Dateisystemen eh nicht so dramatisch sehen kann, wenn es da eh nur bis auf 2 Sekunden genau ist.
-
Ob der Timestamp in meinem Word-Dokument eine Sekunde falsch ist, das ist mir tatsächlich egal. Wenn ich aber zwei Computer habe, deren Systemuhren exakt gleich laufen müssen, dann ist eine Sekunde absolut unbefriedigend. Zum Glück hat das Dateisystem aber nichts mit der Systemuhr zu tun
-
Da mein Internet grade ziemlich rumzickt hab ich mal grade zwei Linuxrechner mit ptbtime1.ptb.de synchronisiert. (Da sich hier noch niemand beschwert hat, dass Google und Wikipedia nicht laufen wirds wohl meine Leitung sein) Auf einem Rechner wurde ein Offset von über Sechs Sekunden errechnet auf dem anderen eins von ~25ms. Trotzdem ticken jetzt beide fast auf die Sekunde genau gleich. Erstaunlich.
Sind WP und Google nur bei mir lahm bis tot?
-
snOOfy schrieb:
Ob der Timestamp in meinem Word-Dokument eine Sekunde falsch ist, das ist mir tatsächlich egal. Wenn ich aber zwei Computer habe, deren Systemuhren exakt gleich laufen müssen, dann ist eine Sekunde absolut unbefriedigend. Zum Glück hat das Dateisystem aber nichts mit der Systemuhr zu tun
Wäre es dann nicht besser, wenn die beiden Computer unter sich eine tausendstel Millisekunde ausmachen? Natürlich basierend auf der NTP-Zeit.
-
anonymous
schrieb:snOOfy schrieb:
Ob der Timestamp in meinem Word-Dokument eine Sekunde falsch ist, das ist mir tatsächlich egal. Wenn ich aber zwei Computer habe, deren Systemuhren exakt gleich laufen müssen, dann ist eine Sekunde absolut unbefriedigend. Zum Glück hat das Dateisystem aber nichts mit der Systemuhr zu tun
Wäre es dann nicht besser, wenn die beiden Computer unter sich eine tausendstel Millisekunde ausmachen? Natürlich basierend auf der NTP-Zeit.
MSDN, Link: siehe ein paar Post's vorher
Der W32Time-Dienst verwendet SNTP (Simple Network Time Protocol) in Microsoft Windows 2000. Der W32Time-Dienst verwendet NTP (Network Time Protocol) in Microsoft Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 und Windows Server 2008 R2.
Wir garantieren nicht, und die Genauigkeit für den W32Time-Dienst zwischen Knoten in einem Netzwerk wird nicht unterstützt. Der W32Time-Dienst ist keine umfassende NTP-Lösung, die zeitkritische Anwendungsanforderungen erfüllt. Der W32Time-Dienst ist in erster Linie dazu konzipiert, um die folgenden Aktionen ausführen:
Stellen Sie das Kerberos Version 5-Authentifizierungsprotokoll arbeiten.
Geben Sie Zeit, lose Synchronisierung für Clientcomputer.Der W32Time-Dienst kann nicht zuverlässig Sync-Zeit, um den Bereich von 1 bis 2 Sekunden aufrechterhalten. Solche Toleranzen sind außerhalb der Entwurfsspezifikation der W32Time-Dienst.
-
Also, die Synchronisation von Windows alleine kann mitunter unzureichend sein, insbesondere wenn man wie ich viele VMs mit Datenpool auf dem File- Server betreibt, die z.T. enorme clock skews haben (über 24 Stunden kommen da schon etliche Sekunden zusammen). Dann kann es durchaus passieren, daß ein Compiler zwar compiliert, aber dann nicht linked, weil die erzeugten module aus der "Zukunft" stammen.
Abhilfe: Ich betreibe auf dem Gatewayrechner einen ntpd, der sich stündlich mit timepool- servern synchronisiert, der fileserver fragt dessen Zeit alle 10 Minuten ab. Die Workstations und VMs synchronisieren auch alle 10 Minuten aufs Gateway mittels http://www.timesynctool.com/.Einen Unterschied zwischen Funkuhren und Rechnerzeiten konnte ich danach nicht mehr ausmachen.
-
Siassei schrieb:
anonymous
schrieb:snOOfy schrieb:
Ob der Timestamp in meinem Word-Dokument eine Sekunde falsch ist, das ist mir tatsächlich egal. Wenn ich aber zwei Computer habe, deren Systemuhren exakt gleich laufen müssen, dann ist eine Sekunde absolut unbefriedigend. Zum Glück hat das Dateisystem aber nichts mit der Systemuhr zu tun
Wäre es dann nicht besser, wenn die beiden Computer unter sich eine tausendstel Millisekunde ausmachen? Natürlich basierend auf der NTP-Zeit.
MSDN, Link: siehe ein paar Post's vorher
Der W32Time-Dienst verwendet SNTP (Simple Network Time Protocol) in Microsoft Windows 2000. Der W32Time-Dienst verwendet NTP (Network Time Protocol) in Microsoft Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 und Windows Server 2008 R2.
Wir garantieren nicht, und die Genauigkeit für den W32Time-Dienst zwischen Knoten in einem Netzwerk wird nicht unterstützt. Der W32Time-Dienst ist keine umfassende NTP-Lösung, die zeitkritische Anwendungsanforderungen erfüllt. Der W32Time-Dienst ist in erster Linie dazu konzipiert, um die folgenden Aktionen ausführen:
Stellen Sie das Kerberos Version 5-Authentifizierungsprotokoll arbeiten.
Geben Sie Zeit, lose Synchronisierung für Clientcomputer.Der W32Time-Dienst kann nicht zuverlässig Sync-Zeit, um den Bereich von 1 bis 2 Sekunden aufrechterhalten. Solche Toleranzen sind außerhalb der Entwurfsspezifikation der W32Time-Dienst.
Meinte ja auch wenn, dann mit einem viel besseren oder einem eigenen.
