Das der Aktualisierungstrigger der Webseiten etwas unterschiedlich ist kann ich noch verstehen. Nur woher kommen die Abweichungen? Was stimmt nun? Letztere wirbt ja auch mit der PTB.
Uhren auf Webseiten anzuschauen und dabei Präzision zu erwarten, mutet schon etwas naiv an.
Für den Zweck wurde das NTP entwickelt – damit kannst du auch verschiedene Quellen vergleichen, indem du nacheinander damit syncronisierst – der Client zeigt dir dann die Abweichung zur vorherigen Zeit an.
Da die Laufzet im Internet unkalkulierbar schwanken kann, einer DCF77 Funkuhr. Da kann man wenigstens anhand des Abstandes zu Mainflingen die Signallaufzeit abschätzen.
Es gibt sicher auch genaue GPS basierte Uhrsysteme.
Die einzigen, die bei mir synchron sind, soweit eine Ablage überhaupt sichtbar ist, sind die beiden PTB-Uhren (digital und analog, https://uhr.ptb.de/).
Also vermutlich weniger als einige ms, vielleicht wenige 10ms Ablage. Das dürfte gerade so die Ping-Zeit sein. Bei denen habe ich auch nie was anderes beobachten können.
Man muß immer auf Plausibilität prüfen, um keine Folgeschäden zu haben!
DCF77 ist das Impustelegramm auch manchmal gestört.
tracert ptb.de ergibt auch verschiedene Laufzeiten deswegen NTP.
https://de.wikipedia.org/wiki/Network_Time_Protocol
Die Seite von der PTB ist jedenfalls die offizielle und mir noch nicht negativ aufgefallen.
Einige andere Webseiten sind mir (wie dir) auch negativ aufgefallen. Offenbar zeigen sie gar nicht die Atomzeit an, sondern wollen dich nur anlocken, damit sie dir Ihre Werbung anzeigen können. Bei Händlern für angeblich hoch präzise Uhren finde ich das besonders peinlich.
Die hochgenaue Zeit auf einem Rechner anzuzeigen ist sowieso schwierig, da CPU-Befehle verschieden lange brauchen. Die Fernsehuhr geht auch nicht genau, weil das Signal schon 3 Sekunden durch das digitale Studio braucht.
Zu DCF77 und NTP gab es schon zahlreiche Diskussiosbeiträge hier im Forum.
Die hochgenaue Zeit auf einem Rechner anzuzeigen ist sowieso schwierig,
Bei so gut wie jedem Betriebssystem wird die Rechner-Zeit automatisch per NTP mit der "Atomuhr-Zeit" synchronisiert, sobald eine Internet-Verbindung besteht.
Und das geht schon recht genau...
1
# ntpdate -q ntp1.ptb.de
2
server 192.53.103.108, stratum 1, offset -0.000922, delay 0.03795
3
18 Jan 19:28:38 ntpdate[37720]: adjust time server 192.53.103.108 offset -0.000922 sec
d.H. die Rechner-Uhr bei mir weicht weniger als 1ms von der Atomuhr-Zeit aus Braunschweig ab.
Für "noch genauer" müsste man u.A. den Delay vom (LCD-)Monitor kennen, der da gerne mal 1 Frame hinterherhinkt. Das sind bei 60Hz dann auch schon 1s/60=16,6ms...
Röhrenmonitore waren da noch berechenbarer.
Damit ist "einfach Rechner-Zeit anzeigen" schonmal besser als alles was irgendwie über Webbrowser läuft. Solange man das halt nicht kaputt-konfiguriert hat.
Voraussetzen möchte ich, dass ich das folgende nicht technisch akribisch betreibe.
Ich beobachte schon seit Monaten das Laufverhalten meiner auf DS3231 Basis betriebenen Nixie Uhr. Zum Zeitvergleich verwende ich die Laufzeit korrigierte Web Zeit Seite "time.is" in Unix Format. Die Nixieuhr läuft intern mit einem UNIX TS Layer auf UTC eingestellt. Zeitzone und DST/MST Einstellung über Eeprom des Nano uC. Unix TS hat über normale BCD Zeit große Betriebsvorteile und deshalb bevorzuge ich dieses Format mittlerweile. Es ist sehr schade, dass es keinen DS323x kompatiblen RTC mit ähnlicher Performanz zu geben scheint.
Mir geht es also nur um die Sekundenauflösung. Bis jetzt läuft die Nixieuhr seit vier Monaten innerhalb des Sekundenschritt Fensters noch ziemlich synchron.
Es scheint, daß für solche Zwecke time.is gut genug übers Netz zu funktionieren scheint.
Es scheint, daß für solche Zwecke time.is gut genug übers Netz zu
funktionieren scheint.
Gerhard
Die Methode der Wahl sollte heute eigentlich GPS sein.
GPS benoetigt selbst die hoechste moegliche Praezision fuer
seine Funktion.
Zeitdienste, die ueber "externe" Netzwerkdienste auf Zeitnormale
zugreifen wollen, sind den Unwaegbarkeiten eben dieser unterworfen.
Das mag regional gut funktionieren, nur eine globale Empfehlung
kann man daraus nicht folgern.
Auch DCF ist wegen der niedrigen, zur Verfuegung stehenden Bandbreite,
schlechter als GPS. Man muss Korrelationsverfahren einsetzen, wenn
man die zeitliche Aufloesung verbessern will.
Keine Ahnung welches Internet ihr habt: Alle genannten Uhren laufen bei
mir unter 1s synchron, auch im Vergleich zu einer DCF77-Uhr.
Ich hab erstmal alle Links direkt hintereinander in neuen Tabs geöffnet. Da waren die bis zu 5s auseinander. Dann alle einzeln einmal refresht und jetzt würde ich auch sagen, dass die so <500ms auseinander sind.
....
Was mir aber auffällt: atomuhr.de geht recht schnell falsch. Wo ich die Zeilen jetzt hier tippe, ist die wieder 5s daneben. Wahrscheinlich nutzen die irgendwie mies nen JS Timeout oder so.
Wenn Web, dann würde ich die vom PTB nehmen. Die Seite ist schön klein, synct die Zeit über schnelle websockets 5x und nimmt dann den Mittelwert (wenn ich das richtig sehe). Unten das deltaT zeigt übrigens den Unterschied zur Systemzeit. Der ist bei mir nie >1ms. Also auch auf Webseiten kann man genaue Uhren anzeigen.
ich habe jetzt auf einem ESP32 einen NTP Client laufen. ptbtime1.ptb.de. Ich aktualisiere aller 100ms die locale tm Struktur und lasse die Zeit ausgeben wenn die Sekunde unterschiedlich zur alten ist.
Die Webseite der PTB läuft syncron. https://uhr.ptb.de/ Logisch, sollte gleich sein vom gleichen Anbieter. :-)
ptbtime1.ptb.de.
Ich aktualisiere aller 100ms die locale tm Struktur
Hört sich falsch an. NTP ist dafür gedacht, die lokale Uhr zu stellen und deren Gangabweichung festzustellen, damit die ausgeregelt werden kann. Nicht als Ersatz für eine lokale RTC.
So ist deine Uhrzeit zwischen den NTP-Updates immer falsch, einfach weil sie stillsteht.
das Espressif-ESP32-Arduino-Framework bringt doch alles mit, das gleich richtig zu machen.
Musst nur
configTime mit deiner Zeitzone und ein bis drei Servern aufrufen, und schon hat der ESP die richtige Zeit, und hält sich an die RFCs zu Abfrageintervallen...
ich habe jetzt auf einem ESP32 einen NTP Client laufen. ptbtime1.ptb.de.
Ich aktualisiere aller 100ms die locale tm Struktur und lasse die Zeit
ausgeben wenn die Sekunde unterschiedlich zur alten ist.
Die Webseite der PTB läuft syncron. https://uhr.ptb.de/ Logisch, sollte
gleich sein vom gleichen Anbieter. :-)
Moin,
Ich habe die ptb Uhr am iPad laufen gehabt und interessanterweise, schaltete der uPad visuell absolut synchron mit der ptb Uhr von 13:41 auf 13:42 um.
Habe die 100ms rausgenommen, funktioniert weiterhin wie gewünscht.
Bei der Config scheint es verschiedene Möglichkeiten zu geben wie ich mitbekommen habe.
1
/*
2
NTP TZ DST - bare minimum
3
NetWork Time Protocol - Time Zone - Daylight Saving Time
Da die Laufzet im Internet unkalkulierbar schwanken kann,
... machen ordentliche NTP mehrere Anfragen und rechnen die Laufzeit heraus. Das hat unter Win_2000 sehr gut funktioniert, im XP hat MS das versaubeutelt. Die uhr.ptb.de zeigt, dass das auch in einer Webanwendung ziemlich gut geht.
Die einzigen, die bei mir synchron sind, soweit eine Ablage überhaupt
sichtbar ist, sind die beiden PTB-Uhren (digital und analog,
https://uhr.ptb.de/).
Also vermutlich weniger als einige ms, vielleicht wenige 10ms Ablage.
Wieso vermutlich?
Klicke auf "Delta t", dann steht hier aktuell
"Die lokale Uhr geht 62 ms nach ± 28 ms"
Das sieht gut aus, aber rufe ich die selbe Seite in unterschiedlichen Browsern auf, differieren deren Werte um einige ms.
Ich musste grad kurz das Datum der Posts anschauen. So ganz nebenbei sind die Handy Basis Stationen auch mit Rubidium Normalen synchronisiert. Bedeutet, das Handy Netz ist auch Atomuhr-genau. Leider werden mir keine Sekunden angezeigt.
Die Fernsehuhr geht auch nicht genau, weil das Signal schon 3 Sekunden
durch das digitale Studio braucht.
Es wäre freundlich von dir, wenn du richtig zitieren würdest. Das da oben kommt nicht von mir, sieht in deinem Posting aber so aus auf den ersten Blick.
Mein Kommentar dazu ist kein Quatsch. Informiere dich bevor du Aussagen anderer als Quatsch bezeichnest und das auch noch ohne Begründung. Aber guter Diskussionsstil liegt dir nicht so. Festzustellen wenn man hier so durchs Forum schaut. Bist eher so der Pöbler?
Da die PTB-Uhren keine merkliche Ablage haben, liegt es nicht am Internet.
Aber diese beiden Seiten mit der bei mir großen Ablage (knapp 30s) zeigen die Rechner-Systemzeit an und nicht DCF!
Leider verweigert meine Rechneruhr seit einiger Zeit die Synchronisation mit der NTP-Zeit und daher ist die Ablage momentan knapp 30s. Ich habe die Zeit gerade manuell korrigiert und siehe da, die Ablage ist jetzt entsprechend kleiner.
Wenn einer eine Idee hat, warum die Synchronisation nicht mehr geht: her damit - ich habe versucht, Infos für den Grund zu finden, war aber bisher erfolglos.
Wenn einer eine Idee hat, warum die Synchronisation nicht mehr geht: her
damit - ich habe versucht, Infos für den Grund zu finden, war aber
bisher erfolglos.
Dazu wär’s zunächst wichtig zu wissen, was für ein Betriebssystem du nutzt. Im Falle von Linux wäre ich ziemlich zuversichtlich, da unterstützen zu können. In dem Fall wäre meine nächste Frage, wofür „geht nicht mehr“ hier steht, welche Fehlermeldung oder welchen Logeintrag der Versuch denn erzeugt.
Im Falle von Windows findet sich hier aber bestimmt auch jemand, der sich damit auskennt.
ich dachte zu irgendwas müssen die Webseiten gut sein.
Na sie zeigen dir die aktuelle Uhrzeit an. Unrealistische Genauigkeitserwartungen kommen schlicht aus deinem Unverständnis für Web-Technologie und deiner Unkenntnis über genau zu diesem Zweck entwickelte spezielle Protokolle wie z.B. NTP.
Dazu wär’s zunächst wichtig zu wissen, was für ein Betriebssystem du
nutzt.
Ja, da hast du natürlich recht.
Ich nutze noch Win 7 und die Fehlermeldung lautet:
"Fehler beim Ermitteln des Status der letzten Synchronisierung. Element nicht gefunden." Siehe Anhang.
An irgendeiner Portsperre im Router kann es nicht liegen, denn ein zweiter Rechner mit Win 7 synchronisiert problemlos.
"Fehler beim Ermitteln des Status der letzten Synchronisierung. Element
nicht gefunden."
Mal irgend ein "Windows-Privatsphäre-Verbesserungs-Registry-haxxor-Tool" verwendet?
Die möchten immer gerne Verhindern, dass dein Windows mit den Microsoft-NTP-Servern Kontakt aufnimmt, aber statt einfach einen anderen NTP(-Pool) einzutragen wird von manchen die Zeitsynchronisation komplett und nachhaltig lahmgelegt.
Mal irgend ein "Windows-Privatsphäre-Verbesserungs-Registry-haxxor-Tool"
verwendet?
Nein, eigentlich halte ich Abstand von solchen Tools. Da das Problem aber schon länger existiert und ich mich nicht mehr an alles erinnern kann - nicht gänzlich auszuschließen. Außerdem ist das ja gar nicht sofort zu bemerken, wenn irgend eine Aktion das Problem verursacht. Die Uhr läuft ja trotzdem.
Und das Windows ist nie erneut installiert worden ...
Es geht auch mit dem times.windows.com nicht oder irgend einem anderen.
Verstehe ich nicht. Soll das Abweichung heißen? Mit dem Handy gespielt?
Richtig. Ich meinte nicht die Ablage in Leitz-Ordnern, sondern im Sinne von "liegt daneben", "Offset", "Differenz", "zeigt falsche Zeit an", "Abweichung" - suche dir was aus ...
Und mein Handy ist ausgeschaltet. Ich sitze am PC.
Extra nochmals für dich:
Die Zeitanzeige der genannten PTB-Webseiten verglichen mit meiner direkt anzeigenden DCF-Uhr lassen keinen Unterschied erkennen. Mit dem Auge verglichen, wohlgemerkt, nicht mit einem Messgerät!
Das Fazit war, dass die beiden Webseiten
http://www.atomuhr-infos.de/
und
https://www.atomuhr.de/
nur die Computersystemzeit anzeigen und keine empfangene DCF-Zeit. Auch wenn sie das behaupten.
Je nachdem wann der PC zum letzten Mal mit einem NTP-Server synchronisiert hatte und wie stabil seine Uhr ist, kann die dort angezeigte Zeit auch mal deutlich abweichen.
Voreingestellt ist das Synchronisationsintervall bei Windows auf eine Woche; wie schon gesagt, mein Windows tut das überhaupt nicht mehr, deshalb habe ich auch etwa 25s Abweichung auf den beiden Seiten beobachten können.
Hinter dem Link wird der alte Stand beschrieben. Heute bekommt man unter einer Adresse automatisch mehrere geprüfte¹ Zeitserver:
1
de.pool.ntp.org
[1] naja, pool.ntp.org sagt, dass die regelmäßig überwacht werden (von wegen "Viele frei verfügbare Zeitserver verteilen eine signifikant falsche Zeit , obwohl sie sich als Stratum-1-Server ausgeben.")
Leider verweigert meine Rechneruhr seit einiger Zeit die Synchronisation
mit der NTP-Zeit
[...]
Wenn einer eine Idee hat, warum die Synchronisation nicht mehr geht: her
damit
Mit welchem Server versuchst du denn zu synchronisieren? Das wäre ja die Minimal-Info, die man bräuchte, um irgendwas Kompetentes dazu sagen zu können...
Außerdem: Was ist deine "Rechneruhr"? Vermutlich die Systemzeit deines OS. Welches ist das? Auch diese Information wäre für eine Analyse irgendwie ganz hilfreich, findest du nicht?
denn ein zweiter Rechner mit Win 7 synchronisiert problemlos.
Vergleiche mal beide Reg-Einträge, inbesondere unter:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
und dort mal:
"LocalNTP"=dword:00000001
"NtpServer"="129.187.254.32,0x1"
"Type"="NTP"
(Der hier eingetragene Server ist nicht unbedingt gleich dem, der in der bunten Oberfläche angezeigt wird!)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00000E10
ist 3600 = jede Stunde, testweise auf einen kürzeren Wert setzen.
Ich weiß nicht, ob es auch Win7 betrifft, XP synchronisiert nicht mehr gegen ptb.de, seit dort vor längerer Zeit eine Änderung erfolgte.
Hole Dir von http://www.satsignal.eu/software/net.htm
(David's Page - Software - Net Tools) seinen "NTP monitor".
Verzeichnis anlegen, auspacken und los, spielt auch auf aktuellen Windows.
Die ClockList.txt händisch anpassen, lokale IPs direkt eintragen.
Mit welchem Server versuchst du denn zu synchronisieren? Das wäre ja die
Minimal-Info, die man bräuchte, um irgendwas Kompetentes dazu sagen zu
können...
Mit diversen versucht - mit keinem geht es.
Außerdem: Was ist deine "Rechneruhr"? Vermutlich die Systemzeit deines
OS. Welches ist das? Auch diese Information wäre für eine Analyse
irgendwie ganz hilfreich, findest du nicht?
Gegen eine lokale GPS-Zeitquelle, ist NTP nur 2. Wahl um eine
praezise Primaerzeit zu beschaffen. Man kann aber seinen lokalen
NTP-Server darauf synchronisieren, um den lokalen $REST zu versorgen.
Passende Hardware: AK172 USB-GPS-Stick (mit uBlox7).
Passende Software: GPStime von COAA.
Die Software muss bei Windows 10 unter dem Systemaccount laufen.
Und Webseitenatomuhren sind dabei natuerlich voellig sinnfrei.
Ein "Informatiker" wuerde wahrscheinlich die Webseite parsen,
um die Zeit zu extrahieren. Das muss man jetzt nicht mehr kommentieren.
Und Webseitenatomuhren sind dabei natuerlich voellig sinnfrei.
Sind sie nicht. Die Uhr von der PTB ist das moderne Pendant der Kirchturm-Uhr, auf die jeder gucken kann, wenn er seiner eigenen Uhr nicht vertraut. Sie ist sogar noch viel genauer und zuverlässiger.
Übrigens berücksichtigt die Uhr der PTB sogar die Laufzeiten im Netz, soweit das mit den Mitteln eines Web-Broesers machbar ist.
Dein Anspruch, dass nur perfekte Lösungen Sinn machen, ist Praxis-fern. Erfolgreiches Leben ist voller Kompromisse.
Ein "Informatiker" wuerde wahrscheinlich die Webseite parsen,
um die Zeit zu extrahieren. Das muss man jetzt nicht mehr kommentieren.
Das muss ich jetzt aber mal kommentieren. Als Softwareentwickler besteht mein Job darin, für die jeweilige Aufgabe eine möglichst einfache/preisgünstige Lösung zu finden, die den Anforderungen genügt. Niemand bezahlt mich für perfekte Lösungen. In meinem Umfeld nennt man das "akademische Lösungen" oder "akademisch aufgebläht". Damit kommt man vielleicht auf der Uni weiter, aber nicht in der Wirtschaft.
ntpd kann sich seit Urzeiten auf alle möglichen lokal angeschlossenen Zeitnormale synchronisieren. Haben wir zu ISDN-Zeiten mit DCF77-Empfängern gemacht, ging aber auch damals schon für diverse GPS-Empfänger.
Wenn du aber wirklich besser werden willst als NTP über (gutes, stabiles) Internet, dann solltest du auch am Empfänger nicht geizen. Dein USB-Stick wäre dann genauso zweite (oder dritte) Wahl.
Aber für solche Diskussionen gibt's doch irgendwo die "time nuts"-Diskussionsliste.
Immerhin schlägt ein lokaler u-blox7 über USB einen Stratum 1 Server über eine Standleitung :) Ich schau fast täglich mal drauf, aber der ntpd auf dem Client bevorzugt immer den lokalen.
1
lokaler NTP-Server 10.10.10.42:
2
remote refid st t when poll reach delay offset jitter
3
+212.18.3.19 212.18.1.106 2 u 38 512 377 4.879 -0.887 1.177
4
*127.127.20.0 .GPS0. 1 l 31 64 377 0.000 -0.446 1.203
5
6
ein NTP-Client:
7
8
+130.133.1.10 .PPS. 1 u 247 1024 377 25.265 75.819 43.374
9
+194.163.182.21 192.171.1.150 2 u 267 1024 377 14.062 34.573 42.121
10
+185.125.190.58 37.15.221.189 2 u 234 1024 377 30.343 28.076 43.949
11
*10.10.10.42 GPS_NMEA(0) 2 u 396 1024 377 1.073 78.597 36.531
ntpd kann sich seit Urzeiten auf alle möglichen lokal angeschlossenen
Zeitnormale synchronisieren. Haben wir zu ISDN-Zeiten mit
DCF77-Empfängern gemacht, ging aber auch damals schon für diverse
GPS-Empfänger.
Gewoehne dich daran, dass frueher™ eben auch mal vorbei ist.
Immerhin kann man dem Windows 10 "ntpd" eine lokale Zeitquelle
unterschieben
Wenn du aber wirklich besser werden willst als NTP über (gutes,
stabiles) Internet, dann solltest du auch am Empfänger nicht geizen.
Dein USB-Stick wäre dann genauso zweite (oder dritte) Wahl.
Vermutlich hast du so einen Stick noch nicht mal von aussen gesehen.
Aber für solche Diskussionen gibt's doch irgendwo die "time
nuts"-Diskussionsliste.
Abseits dieser Foren, kann man durchaus auf aktuell verfuegbare
Technik hinweisen.
ntpd kann sich seit Urzeiten auf alle möglichen lokal angeschlossenen
Zeitnormale synchronisieren. Haben wir zu ISDN-Zeiten mit
DCF77-Empfängern gemacht, ging aber auch damals schon für diverse
GPS-Empfänger.
Gewoehne dich daran, dass frueher™ eben auch mal vorbei ist.
Was hat das damit zu tun?
Der kann das natürlich auch heute noch machen. Aber heute™ genügt mir NTP via Internet vollauf.
Erst wenn ich mehr als das wöllte, würde ich mir Gedanken um einen GPS-Empfänger machen, den würde ich dann aber vorzugsweise direkt an eine Hardware anbinden, ohne sowas wie USB.
Vermutlich hast du so einen Stick noch nicht mal von aussen gesehen.
Ich habe genügend u-blox-Teile gesehen und auch hier. Die sind gut, keine Frage, aber USB ist halt trotzdem noch was anderes als ein Hardware-Pin für die Synchronisation.
Genereller Nachteil von GNSS: man braucht halt 'ne Antenne draußen.
Genereller Nachteil von GNSS: man braucht halt 'ne Antenne draußen.
Und zwar stabil angeschraubt auf dem Dach mit Blitzschutz und fingerdickem Koaxkabel und so. Oder eben per USB drinnen auf dem Serverschrank oder notfalls auf der Fensterbank ;)
den würde ich dann aber vorzugsweise direkt an
eine Hardware anbinden, ohne sowas wie USB.
Ja wenns nicht mehr Wuensche sind.
Der in den (AK172-)Sticks verbaute uBlox7, hat sowohl noch ein
echtes serielles Interface, als auch einen in weiten Grenzen
programmierbaren PPS-Ausgang.
Bislang reicht mir USB aber. Wenn es mal mehr als 5 m werden sollten,
werde ich mir den TX am Chip nochmal genauer ansehen.
Der in den (AK172-)Sticks verbaute uBlox7, hat sowohl noch ein
echtes serielles Interface, als auch einen in weiten Grenzen
programmierbaren PPS-Ausgang.
Schon klar, ich schrieb ja, dass ich die Teile kenne. Könnte man an einen kleinen SBC hängen, der dann NTP-Server via Ethernet spielt.
Das muss ich jetzt aber mal kommentieren. Als Softwareentwickler besteht
mein Job darin, für die jeweilige Aufgabe eine möglichst
einfache/preisgünstige Lösung zu finden, die den Anforderungen genügt.
Ja, das ist so. Aber: Wenn deine Lösung zur Zeitsynchonisation darin besteht, das du statt eines primitiven SNTP-Client einen einen "Full-Blown" Web-Client beschaftigen musst, dann benutzt du definitiv irgendwie die falschen Werkzeuge.
Das dürfte dann wirklich unter die "Hammer->Nagel-Problematik" fallen...
Ja, das ist so. Aber: Wenn deine Lösung zur Zeitsynchonisation darin
besteht, das du statt eines primitiven SNTP-Client einen einen
"Full-Blown" Web-Client beschaftigen musst, dann benutzt du definitiv
irgendwie die falschen Werkzeuge.
https://uhr.ptb.de/ behauptet übrigens für meinen PC eine Abweichung von 2 bis 3 ms – allerdings mit einer Messunsicherheit von ±17 ms. Auf dem Handy ist die berechnete Abweichung allerdings über 200 ms.
Allenfalls waere beim Ganzen noch interessant, was das Projekt soll.
Atomuhrgenauigkeit brauchen eigentlich die wenigsten Leute. Und diewelchen, die's brauchen fragen weniger nach den Kosten. Haben zB eine Rubidium Uhr welche auf das GPS synchronisiert ist, falls sie denn keine CS Uhr haben.
Diesen Leuten geht es normalerweise um die Frequenz, resp den Jitter, weniger um den Versatz zwischen zwei Uhren. Der Versatz ist fuer normale Leute Null. Fuer weniger normale Leute gehen die Atomuhren verschieden, auch verschieden schnell.Wenn man sie nebeneinander stellt gehen sie gleich schnell.
Da kommt dann rein, dass es gemaess Einstein keine absolute Zeit gibt. Also neben der berechenbaren Laufzeit kommt noch die Beschleunigung hinzu, resp die Raumkruemmung.
Fuer weniger normale Leute gehen die Atomuhren verschieden,
auch verschieden schnell. Wenn man sie nebeneinander stellt
gehen sie gleich schnell.
Nicht unbedingt. Deshalb wird die internationale Zeit nicht von einer
sondern von mehreren in verschieden Ländern aufgestellten Uhren und
deren gewichtestes Mittel festgelegt. Die Zeitverschiebung auf Grund
der Höhe über N.N. der Uhren wird vorher rausgerechnet.