• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

ntp für sehr exakte Zeitsynchronisation?

Herakles

Profifragensteller
Themenstarter #1
Moin!

Ich möchte in einem LAN inklusive WLAN auf schätzungsweise 20 Rechnern dieselbe Uhrzeit haben. Diese soll so genau wie eben möglich sein, muss aber nicht zwangsläufig die "reale" Zeit sein - es kann also eine "eigene" Zeit im Netz existieren, primär ist es wichtig, dass die Abweichung aller Rechner minimalst ist!

Ist soetwas mit ntp zu realisieren und falls ja - hat jemand brandheiße Tipps zur Einrichtung oder gar ein Howto? Auf welche Stolpersteine ist zu achten? Spielen die Paketlaufzeiten hier eine Rolle? Behindert vielleicht das WLAN einen exakten Abgleich?

Daraus ergibt sich auch die Frage, wie genau ein Rechner eine einmal gestellt Uhrzeit halten kann (vollkommen abgesehen von Spannungsausfällen, Genauigkeit ist nur ohne jeden reboot notwendig).

Am Rande: ich habe mir mal OpenNTPD ein wenig näher angesehen und dort findet sich ein Eintrag wie: "Wir sind nicht hinter den letzten Mikrosekunden her." openntpd.org Das ist also wohl nicht das Projekt meiner Wahl - oder doch?

Danke im Voraus,
Herakles
 
Zuletzt bearbeitet:

nakal

Anfänger
#2
Es ist ja gerade die Idee von NTP, dass die Laufzeiten der Pakete berücksichtigt werden. Für "arme Leute" reicht einfach die Zeit im Kreis zu aktualisieren, per Time-Protocol oder so.

Trag doch einfach mehrere offizielle NTP-Server ein. Je niedriger der Stratum-Wert, desto besser ist die Qualität. Wenn Du etwas zuverlässig genaues haben willst, für zum Beispiel wissenschaftliche Zwecke, dann empfiehlt es sich auch in Braunschweig oder wo auch immer die Atomuhren und die wichtigsten Stratum1-Server stehen anzurufen. Vielleicht kriegst Du einen priviligierten Zugang. Aber so etwas habe ich noch nie versucht, weil mir 100el von Sekunden genügen als Genauigkeit.
 

Herakles

Profifragensteller
Themenstarter #4
Vielen Dank für die ersten schnellen Antworten, ich möchte aber noch einmal herausstellen, dass es nicht zwingend darum geht, die "reale" Zeit auf allen Rechnern zu haben. Es kann auch eine Netzwerkinterne Zeit sein, die ein im LAN befindlicher Rechner vorgibt. Es ist denkbar, dass das gesamte aufgebaute Netzwerk gar keinen Internetzugang hat. Wichtig ist nur geringe realtive Abweichung der Rechner untereinander.
 

walt

Well-Known Member
#5
Alle NTPD's laufen, auf Dauer gesehn, nicht sehr zuverlaessig,
jedenfalls nach meiner persoenlichen Erfahrung.
Oft bleibt der Prozess haengen, verhaspelt sich und Du hast mehrere Sekunden Abweichung im LAN.

Eine Untersuchung habe ich mir aus Zeitgruenden geschenkt, ausserdem war es mir
einfach zu bloed solche Fehler bei einem Praezisionswerkzeug wie dem NTPD
feststellen zu muessen.

Wenn Du etwas haben moechtest was Du einstellst und danach vergessen kannst,
weil Du nie mehr Fehler damit hast, dann ist es folgendes:

Kompilier' den NTPD und installiere daraus nur den ntpdate.
Dann folgende Zeile in die root crontab:
@hourly /usr/local/sbin/ntpdate 10.20.30.1 10.20.30.2 > /dev/null 2>&1

Falls Du mit einer Genaugkeit "auf die Sekunde" zufrieden bist,
hast Du hiermit eine Loesung die absolut zuverlaessig ist und um die Du Dich nie mehr kuemmern musst.
 

MrMarv

Well-Known Member
#6
Eigenen ntpd auf einem der Rechner aufsetzten und alle Clients regelmäßig (cron, 5 Minuten) 'ntpdate' ausführen lassen. Nungut, dann hast du einen Single-Üpoint-of-failure aber dafür im ganzen Netz die Uhrzeit die der eine Rechner vorgibt.

Aber wie hier schon gefragt wurde, für was brauchst du so genaue Zeit, genauer als 100/s?

Grüße!
 

Athaba

Libellenliebhaber
Mitarbeiter
#7
@MrMarv: Das ist doch ein Blödsinn!
Bei der Zeit geht es darum, dass du einmal eine Exakte Zeit braucht (und die kann ntpd auf mehr als 1/100 genau synchronisieren), danach willst du wissen, wie falsch deine Hardware getaktet ist und versuchst das möglichst genau auszubügeln. ntpd als daemon laufen zu lassen ist deshalb sinnvoller, als ein dauerndes ntpdate.

Wenn du die Zeit in einem eigenen Netz synchronisierst, dann kannst du dir fas 100%ig sicher sein, dass wenn du alles richtig konfiguriert hast und ntpd verwendest der Unterschied (sehr weit) unter 100ms sein wird. Wenn du das Setup erst mal hast kannst du es aber relativ einfach überprüfen und sagen, ob es genug ist. Dann könntest du ja auch mal einen Benchmark zur Genauigkeit der diversen Server machen.

@walt: Wie kommst du darauf, dass ntpds andauernd hängen bleiben o.ä.?

EDIT: vielleicht hilft dir das: http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK
 
Zuletzt bearbeitet:

walt

Well-Known Member
#9
@Athaba: Weil das, wie bereits oben geschrieben, meine persoenliche Erfahrung ist.
In Zahlen ausgedrueckt, waren das etwa 6 bis 7 Vorkommnisse auf ungefaehr 1 Jahr verteilt.
Und das auf den unterschiedlichsten OpenBSD Releasestaenden.
NTPD und OpenNTPD.

Nach Einsatz der angeblich "voellig sinnlosen und fehlertraechtigen" Methode
mit ntpdate per cron ist es nie wieder vorgekommen, dass ich zeitliche Abweichungen im LAN hatte.

Wie bereits gesagt, eine Genauigkeit (Abweichung) von 1 Sekunde reicht mir voellig aus.
(Das ist das was ich an Abweichung erreiche, so genau muss es aber gar nicht sein.)
Ausserdem habe ich wichtigeres zu tun als mich mit Software zu beschaeftigen,
die langfristig gesehen, nicht zuverlaessig funktioniert.

Eure Praemissen moegen andere sein.
 

Athaba

Libellenliebhaber
Mitarbeiter
#10
@walt: Hast du das mal reported? Ich habe noch keine negativen Erfahrungen gemacht. Solange es dir passt, ist es ja okay, aber das klingt nicht nach den Anforderungen, die der Threadersteller hat.

@killer: Sinnvoll ist sinnvoller ;)
 
#11
Nach Einsatz der angeblich "voellig sinnlosen und fehlertraechtigen" Methode
mit ntpdate per cron ist es nie wieder vorgekommen, dass ich zeitliche Abweichungen im LAN hatte.
Ich habe hier ziemlich viel per NFS durcheinandergemountet. Wenn da die Zeiten nicht passen, passieren wirklich seltsame Dinge.

Ausserdem lasse ich einige Maschinen remote loggen. Da ist es auch ganz hilfreiche, wenn es keine Zeitspruenge gibt.
 

Herakles

Profifragensteller
Themenstarter #12
Eure Antworten bringen mich glaube ich alle ein Stückchen näher an die Wahrheit - wirklich Erfahrung werde ich da wohl selbst sammlen müssen. Aber genügend Fingerzeige habe ich bis hierher zweifelsfrei bekommen. Danke dafür.

Um die einzige aufgetauchte Frage zu beantworten: eine Genauigkeit von einer Sekunde reicht mir bei weitem nicht. Ich will es so genau wie eben möglich, da sollte es schon in den Millisekundenbereich gehen. Das, was die entsprechende Software hergibt, sollte voll ausgenutzt werden und die Software, die am besten synchronisiert, wird es dann auch werden. Exakte Synchronisation ist oberste Prämisse in meinem Anwendungsfall.

Grüße aus der jetzigen Sommerzeit,
Herakles

P.S.: ich würde auch gerne ein Zeitmaschine bauen, bei all den Zeitgedanken hier. Und ja, ich werde sie in einen De Lorean bauen :D
 

Schläfer

Well-Known Member
#13
Exakte Synchronisation ist oberste Prämisse in meinem Anwendungsfall.
Dann schraub eine Atomuhr an jeden Rechner und gib Frieden.
Wie bitte? Zu teuer? Also doch nicht oberste Prämisse.

Definiere den zulässigen Fehler, dann kann man dir sagen ob Lösung X dein Problem löst.

Mit OpenNTPD bekommt man im lokalen Netz zuverlässig Abweichungen unter 10 ms hin. Vorraussetzung ist, dass immer genügend Luft im Netz und auf der Maschine ist. Mir fällt grade keine Applikation ein, bei der weniger sinnvoll ist, jedenfalls keine, die ich auf einem 08/15-OS laufen lassen möchte.

Um Zeitmessungen im us-Bereich auszuwerten, sollte schon ein Echtzeit-OS her, ein BSD gibt dir keinerlei Garantie, dass ein Ereignis und die zugehörige Zeitnahme innerhalb eines bestimmten Zeitraums passieren. Synchronisation auf deutlich unter einer ms ist hier sinnlos.

Behindert vielleicht das WLAN einen exakten Abgleich?
Vielleicht. Durchsatz und damit u.U. die Umlaufzeit hängen von den Empfangsbedingungen ab.

Es gibt noch DCF77-Empfänger.

JFTR: Es gab voriges Jahr (oder wars sogar schon 2007?) Probleme mit OpenNTPD, ist aber spätestens seit 4.4 Geschichte.
 

Illuminatus

in geheimer Mission
#14
der Anwendungsfall würde mich interessieren. OpenNTP als Daemon laufen zu lassen würde ich als erstes umsetzen. Eine Überwachung der Genauigkeit kannst du mit Plugins für Nagios messen. Außerdem exisitieren Munin plugins wenn einen die Abweichung in grafischer Form interessiert.

x86 ist nicht unbedingt bekannt dafür gute Zeitgeber zu haben.

Um das Problem zu umgehen: kannst du die Anwendung evt. auf einen einzigen (Terminal)Server laufen lassen? User würden dann Remote die Anwendung benutzen.

Wenn es derart zeitkritisch ist was du installierst, kann ich mir vorstellen dass Echtzeitunterstützung in deinem Betriebssystem eine Anforderung ist. Desweiteren würde ich WLAN aus dem Konzept streichen, und ein zuverlässiges Medium wählen.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#15
Wenn es extrem genau sein muss oder keine permanente Internetverbindung besteht, kann man mit dem von Schläfer schon genannten DCF77-Empfänger einen eigenen Stratum 0 Server aufsetzen, zum Beispiel mit einer Soekris. FreeBSD hat mehrere Time-Geeks im Team, ist daher durch entsprechende interne Zeitzähler und weiteres bestens für sowas geeignet. Wie es mit den anderen BSDs ausschaut, weiß ich nicht. Wenn DCF-77 nicht ausreichend genau ist, gibt es noch GPS. Dort benötigt die Antenne aber einen freien Blick auf den Himmel, sie muss also im Freien stehen. Genauer als GPS geht es kaum, zumindest nicht ohne immensen Aufwand.
Diesen Stratum 0 Server lässt man sich erst einmal einpendeln, sprich einige Tage im Leerlauf laufen. Anschließend kann man ihn als Server für die Workstations und / oder Server nutzen. Netzwerklatenz bekommt man dank NTP fast vollständig raus, einzige Ausnahme ist ein überlastetes Netzwerk, was aber generell nicht wünschenswert wäre. Denk aber auch hier daran, ein NTP-Daemon auf einem Client benötigt einige Zeit sich einzupendeln, knappe 20 bis 30 Minuten. Eine Zeitsynchronisation beim Start zu erzwingen - Option -q - ist daher zu empfehlen, ebenso ein Driftfile. Mir dem kann man, wenn es nach einigen Tagen ausreichend gefüllt ist, einen Serverausfall für mehrere Stunden überbrücken, ohne das die Abweichung der Uhrzeit nennenswert groß wird. Zumindest, solange die Systemuhr berechenbar falsch geht. Wenn sie rumeiert, ist murks. Setzt man das korrekt auf, kommt man in den Bereich von wenigen Millisekunden, eventuell aber auch da runter. Nur ein verkabeltes LAN würde ich für eine so hohe Genauigkeit schon als zwingend bezeichnen, WLAN ist zu unberechenbar. Am besten auch gleich noch mal QoS ins Augen fassen.

Davon einmal abgesehen, wofür eine so hohe Genauigkeit? Selbst die extrem zeitkritischen Industrieanwendungen, die mir bekannt sind, bewegen sich im Bereich einer bis ab und an sogar zwei Sekunden maximaler Tolleranz. Auch wenn diese nur für Ausnahmefällen genutzt werde sollten, versteht sich.
 

Herakles

Profifragensteller
Themenstarter #17
Nur um kurz die Fragen nach der Anwendung klarzustellen: ich möchte Multimediadaten an mehreren Empfänger gleichzeitig versenden und die sollen überall möglichst zeitgleich wiedergegeben werden, damit keine wahrnehmbaren Verzögerungen entstehen.

Danke für alle Ideen.
 

MrMarv

Well-Known Member
#18
Nur um kurz die Fragen nach der Anwendung klarzustellen: ich möchte Multimediadaten an mehreren Empfänger gleichzeitig versenden und die sollen überall möglichst zeitgleich wiedergegeben werden, damit keine wahrnehmbaren Verzögerungen entstehen.
[...]
Okay. Vielleicht stehe ich gerade voll aufem Schlauch, aber was hat das mit der Uhr der "Clients" zu tun?
Die Daten per Broadcast rausschicken, währen schon alle Clients drauf lauschen, sollte doch ziemlich genau gleich schnell sein... außer vielleicht Verzögerungen beim Bildaufbau durch lokal unterschiedlichen Workload oder Hardware.

Grüße!
 

Kamikaze

Warrior of Sunlight
Mitarbeiter
#19
Ich denke auch hier wäre die Latenzzeit interessanter. Die Clients müssten Puffern und die Latenzzeit (ping) zum Server mit einrechnen um gleichzeitig zu spielen.

Im lokalen Netz kann man ja sogar Brodcast verwenden um unnötigen Traffic zu vermeiden. Eine Technik die auf Grund des T-Online Boykotts in Deutschland leider zu selten zum Einsatz kommt.
 

*Sheep

des Unterseepudels Kern
#20
Mensch, mensch, mensch... Genau dass machen ja die Zeitdienste. Sie berechnen und berücksichtigen die Laufzeit zur Zeitquelle (die als genau angesehen wird -- Referenz). Es gibt da Stufen (Stratum), min -> max.
Die Atomuhr bei der ptb wird als Stratum0 angesehen (DIE "Zeit" also). Das heißt die Zeitserver(ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de) bei der PTB sind stratum1. Wenn Du deinen NTPD mit den Zeitservern der PTB synchronisierst, dann hast Du, wenn Du die Zeit weitergibst (z.B. ins LAN/WLAN), einen Stratum2 Server usw. Die PTB berücksichtig auch die Schaltsekunden zu Silvester aller drei Jahre etc... Der ntpd passt nebenbei auch die Schrittweite der Rechneruhr an. Der laufende Dienst zwingt der Uhr "Ganggenauigkeit" auf.

Ich würde eine zentrale Dose im Netz mit einer externen Zeitquelle abgleichen z.B. PTB. Alles anderen Geräte würde ich mit der zentralen Dose abgleichen. Die Laufzeiten im LAN/WLAN sollten nun nicht _so_ schlecht sein.

Uhrzeit: http://www.ptb.de/de/zeit/uhrzeit.html
Zeitableich mit NTP: http://www.ptb.de/de/org/q/q4/q42/ntp/ntp_main.htm
alt. Stratum1: http://atom.uhr.de
Zeitverteilung: http://www.eecis.udel.edu/~mills/ntp/html/index.html
Zeitübertragung: http://www.ptb.de/de/org/4/44/442/index.htm
Liste der Zeitabgleichs/Frequenzsoftware: http://tf.nist.gov/general/softwarelist.htm