Moin, welche Möglichkeiten gibt es, über ein Netzwerk (Internet) Ereignisse an verschiedenen Computern ohne Spezialhardware zu synchronisieren? Als erstes fällt mir der Zeitabgleich ein. Man einigt sich darauf, um eine bestimmte Uhrzeit soll auf allen Computern das Ereignis stattfinden. Allerdings haben normale PC meines Wissens keine absolut genaue Uhr. Also bliebe NTP oder ähnliches. Das ist aber laut Wikipedia 'nur' auf etwa 10 ms genau. Geht das irgendwie noch genauer, wenn die Absolutzeit nicht wichtig ist? Gibt es da noch irgendwelche Tricks? Die Synchronisation sollte nach vielleicht maximal einer Minute stehen. Wie gesagt, es ist nicht wichtig, dass die Ereignisse zu einem bestimmten Zeitpunkt auftreten, sondern nur, dass sie möglichst Zeitgleich auftreten. Wie viel ist 'möglichst' auf normalen PC?
Dussel schrieb: > Geht das irgendwie noch genauer Da kommt man unweigerlich in den Bereich, in dem die Lichtgeschwindigkeit zu berücksichtigen ist. Um z.B. die Gleichzeitigkeit auf 1 µs festzulegen, mus der Abstand auf 300 m genau bekannt sein. Und dazu kommen natürlich Einflüsse wie die geringere Lichtgeschwindigkeit in der Luft der Atmossphäre, mit Wetter usw. Wegen der Krümmung der Erdoberfläche und Reflektionen an Hindernissen kommen als Signalgeber nur hoch über dem Horizont stehende Satelliten in Frage. Bei heutigen Halbleiterschaltungen stellt sich die Frage der Gleichzeitigkeit ja schon auf eine Leiterplatte, da weniger als 30 cm = 1 ns. Das muss bei der Taktverteilung berücksichtigt werden. Georg
Hmm:
1 | remote refid st t when poll reach delay offset jitter |
2 | ============================================================================== |
3 | 127.127.1.0 .LOCL. 10 l 32d 64 0 0.000 0.000 0.000 |
4 | *192.168.3.254 195.145.119.188 3 u 6 1024 377 0.208 0.428 0.072 |
5 | +2003:2:2:140:19 172.20.96.197 2 u 774 1024 377 28.115 -1.042 0.678 |
Ich sehe da eine Abweichung <1 ms gegen einen lokalen(!) NTP Server. Wenn der über Internet (DSL, TV-Kabel o.ä.) geht, hast Du immer Probleme mit ungleichmäßigem Jitter, das können abends viele ms sein. Genauer geht es nur mit GPS, und dann will man auch kein Windoof als OS benutzen. Dussel schrieb: > Die Synchronisation sollte nach vielleicht maximal einer Minute stehen. Das reicht IMHO nicht um den Drift der Clock genau genug zu steuern. Normale NTP Server/Clients machen einen Slow Start, damit es keine plötzlichen Sprünge in Datum und Uhrzeit gibt. Dem kann man aber abhelfen.
Frag mal bei der Börsen-IT nach: beim HighSpeedTrading ist denen sowas sehr wichtig.
Z.B. IEEE 1588 bei LXI zum synchronen Triggern über Ethernet benutzt (~20 ns Auflösung, teilweise wohl besser)
Georg schrieb: > Um z.B. die Gleichzeitigkeit auf 1 µs festzulegen, mus der Abstand > auf 300 m genau bekannt sein. So genau muss es nicht sein. Da ich davon ausgehe, dass viel mehr nicht geht, habe ich auf eine genau Angabe verzichtet. Möglichst wenig ist gut, aber im Millisekundenbereich (vielleicht so bis zu drei) kann es schon liegen. Jim M. schrieb: > Wenn der über Internet (DSL, TV-Kabel o.ä.) geht, hast Du immer Probleme > mit ungleichmäßigem Jitter, das können abends viele ms sein. Deshalb die Frage, ob es da irgendwelche Tricks gibt. Jim M. schrieb: > Genauer geht es nur mit GPS, und dann will man auch kein Windoof als OS > benutzen. Oder Funkuhr, aber beides gibt es in einem normalen PC nicht. GOLDESEL schrieb: > Frag mal bei der Börsen-IT nach: beim HighSpeedTrading ist denen sowas > sehr wichtig. Im Millisekundenbereich? Ich sehe es mir mal an. Andre R. schrieb: > Z.B. IEEE 1588 bei LXI zum synchronen Triggern über Ethernet benutzt > (~20 ns Auflösung, teilweise wohl besser) Dann suche ich mal danach, auch wenn für ich unter Ethernet eher was lokales verstehe.
IEEE 1588, Precision Time Protocol, wäre vielleicht eine Möglichkeit. Allerdings ist das nicht so einfach wie NTP, und das Protokoll alleine reicht nicht, man braucht trotzdem gute Uhren.
Theoretisch hat man 2 Probleme, Ungenauigkeit der lokalen Uhr und Ungenauigkeit in der Kommunikationslatenz (im Sinne von nicht deterministisch). Und man muss sich ueberlegen ob es zentral (es gibt einen der bestimmt), oder dezentral (alle einigen sich auf etwas) geloest werden soll. Das dezentrale Problem ist als (distributed) Firing Squad bekammt und aehnlich dem (distributed) Consensus/Synchronization/Unison Problem. Fan und Lynch [1] zeigen in 'Gradient Clock Syncthronization' zum Beispiel im dezentralen Fall das
eine untere Schranke fuer den Uhrendifferenz benachbarter Knoten ist. Wo d die Distanz der Knoten ist und D der Durchmesser des Kommunikationsgraphen. Auf deutsch, selbst die Zeitdifferenz direkt benachbarter Knoten haengt von der Groesse des Netzwerkes ab. Im Zentralen Fall, zum Beispiel ein Server koordiniert alles, hat man keine Abhaengikeit von D, sondern nur von d (und der Praezision der lokalen Uhr und den unterschiedlichen Packetlaufzeiten). In der Praxis wuerde sich Synchronisation ueber GNSS anbieten (im Bereich (weit) unter 100 ns), insbesondere wenn alle Rechner ueber das Internet verteilt sind. Dies ist besser als man ueber das Internet erreichen kann. Das ist zum Beispiel eine der Methoden um die Atomuhren der nationalen metrologischen Institute zu vergleichen. PTP braucht Hardwareunterstuetzung in Switch und Netzwerkkarte, damit es seine volle Leistung erreicht (Latenz durchs Kabel ist fast konstant, Zeitstempel wenn das Packet am Switch empfangen und wieder gesendet wird, ermoeglichen die nichtdeterministische Latenz in der Switchhardware heraus zu rechnen). Zwar kann man PTP auch in Software laufen lassen, aber das Hauptfeature, die Unterschiede in den Packetlaufzeiten heraus zu rechnen, funktioniert dann nicht. Man ist dann auch nicht viel besser dran als mit NTP. [1]: http://groups.csail.mit.edu/tds/papers/Fan/FanLynch-gradient.pdf
:
Bearbeitet durch User
Andre R. schrieb: > IEEE 1588 Andre R. schrieb: > https://sourceforge.net/projects/ptpd/ > > https://code.google.com/archive/p/ptpv2d/ Jack schrieb: > IEEE 1588, Precision Time Protocol PTP scheint ja nur für lokale Netzwerke gedacht zu sein. Thomas P. schrieb: > In der Praxis wuerde sich Synchronisation ueber GNSS anbieten (im > Bereich (weit) unter 100 ns), insbesondere wenn alle Rechner ueber das > Internet verteilt sind. […] > PTP braucht Hardwareunterstuetzung in Switch und Netzwerkkarte, damit es > seine volle Leistung erreicht (Latenz durchs Kabel ist fast konstant, > Zeitstempel wenn das Packet am Switch empfangen und wieder gesendet > wird, ermoeglichen die nichtdeterministische Latenz in der > Switchhardware heraus zu rechnen). […] Man ist > dann auch nicht viel besser dran als mit NTP. Also wohl doch mit NTP probieren. Die Ereignisse können zentral von einem Master vorgegeben werden.
Dussel schrieb: > Als erstes fällt mir der Zeitabgleich ein. Man einigt sich darauf, um > eine bestimmte Uhrzeit soll auf allen Computern das Ereignis > stattfinden. Allerdings haben normale PC meines Wissens keine absolut > genaue Uhr. Also bliebe NTP oder ähnliches. Das ist aber laut Wikipedia > 'nur' auf etwa 10 ms genau. Geht das irgendwie noch genauer, wenn die > Absolutzeit nicht wichtig ist? Gibt es da noch irgendwelche Tricks? Selbst wenn es wesentlich genauer ginge, hilft dir das garnix, solange du in einem Userspace-Programm unter den üblichen OS für "normale PC" arbeitest. Das sind alles OS mit preemptiven Multitasking und da kann es sehr leicht passieren, dass dein Programm einfach mal 20ms garnicht zum Zuge kommt. Schlimmer noch: wenn's mit dem Speicher eng wird, können aus 20ms auch leicht mal 200 oder 2000ms werden... Sprich: du kümmerst dich um Probleme, die völlig irrelevant sind... Du musst schon Treiber schreiben, damit sie wirklich für dich relevant werden können...
Jim M. schrieb: > Genauer geht es nur mit GPS, und dann will man auch kein Windoof als OS > benutzen. Ja. Es gibt ja GPS-Empfänger mit PPS-Ausgang. Die geben sehr genau einmal pro Sekunde einen Impuls aus. Dussel schrieb: > GOLDESEL schrieb: >> Frag mal bei der Börsen-IT nach: beim HighSpeedTrading ist denen sowas >> sehr wichtig. > Im Millisekundenbereich? Ja. Da das heutzutage automatisiert per Computer gemacht wird, ist es entscheidend. Es ist vollkommen pervers, wird aber gemacht. c-hater schrieb: > Selbst wenn es wesentlich genauer ginge, hilft dir das garnix, solange > du in einem Userspace-Programm unter den üblichen OS für "normale PC" > arbeitest. Das sind alles OS mit preemptiven Multitasking und da kann es > sehr leicht passieren, dass dein Programm einfach mal 20ms garnicht zum > Zuge kommt. Das hat nichts damit zu tun, dass das Scheduling preemptiv ist, sondern damit, dass es für Desktop-Anwendungen ausgelegt ist. > Schlimmer noch: wenn's mit dem Speicher eng wird, können aus 20ms auch > leicht mal 200 oder 2000ms werden... Mit Linux und PREEMT_RT-Kernel bekommt man je nach Rechner auch 30 µs zuverlässig hin. Das Problem ist bei der Konfiguration dann weniger das Betriebssystem, sondern eher die Hardware, insbesondere der SMI.
c-hater schrieb: > Das sind alles OS mit preemptiven Multitasking und da kann es > sehr leicht passieren, dass dein Programm einfach mal 20ms garnicht zum > Zuge kommt. Hier stellst du, wohl wegen fehlender Grundkenntnisse, die Tatsachen auf den Kopf - nur mit preemptiven Multitasking ist Echtzeitverhalten überhaupt möglich. Zitat Wikipedia: The term preemptive multitasking is used to distinguish a multitasking operating system, which permits preemption of tasks, from a cooperative multitasking system wherein processes or tasks must be explicitly programmed to yield when they do not need system resources. Deswegen wird kooperatives Multitasking ja auch seit Win32 nicht mehr benutzt. Richtig ist, dass Windows oder Linux keine Echtzeitsysteme sind, aber die Begründung ist absurd. Georg
Rolf M. schrieb: > Dussel schrieb: >> GOLDESEL schrieb: >>> Frag mal bei der Börsen-IT nach: beim HighSpeedTrading ist denen sowas >>> sehr wichtig. >> Im Millisekundenbereich? > > Ja. Da das heutzutage automatisiert per Computer gemacht wird, ist es > entscheidend. Es ist vollkommen pervers, wird aber gemacht. Das habe ich vergessen zu schreiben. Ich habe mir mal die Grundlagen durchgelesen und es ist anscheinend nicht so, dass da was synchron läuft, sondern dass Makler in die Nähe der Börse ziehen, um Zeitvorteile zu haben.
Rolf M. schrieb: > Das hat nichts damit zu tun, dass das Scheduling preemptiv ist Oh doch, natürlich hat das damit zu tun. > sondern > damit, dass es für Desktop-Anwendungen ausgelegt ist. Damit allerdings AUCH. >> Schlimmer noch: wenn's mit dem Speicher eng wird, können aus 20ms auch >> leicht mal 200 oder 2000ms werden... > > Mit Linux und PREEMT_RT-Kernel bekommt man je nach Rechner auch 30 µs > zuverlässig hin. 30µs?! Für Userspace-Tasks? Das mußt du mir zeigen. Ich sage: Entweder begreifst du nicht, was der RT-Kernel tut (bist also einfach nur doof, das wäre immerhin verzeihlich) oder du LÜGST wider besseren Wissens. Das allerdings wäre unverzeihlich...
Georg schrieb: > Hier stellst du, wohl wegen fehlender Grundkenntnisse, die Tatsachen auf > den Kopf - nur mit preemptiven Multitasking ist Echtzeitverhalten > überhaupt möglich. Nein, das hast du nicht richtig verstanden, wohl wegen fehlender Grundkenntnisse... Solange für jeden einzelnen Task das Zeitverhalten garantiert ist, ist selbstverständlich auch bei kooperativem Multitasking für das Gesamtsystem das Zeitverhalten garantiert. Dazu kommt: de facto hat man es immer mit einem kooperativen Multitasking zu tun, selbst wenn der Task-Scheduler preemptiv arbeitet. Aber das hast du wohl wegen mangelnder Grundkenntnisse wohl auch niemals verstanden...
c-hater schrieb: > Rolf M. schrieb: > >> Das hat nichts damit zu tun, dass das Scheduling preemptiv ist > > Oh doch, natürlich hat das damit zu tun. Nun gut, aber nur in dem Sinne, dass präemptives Scheduling oft von Vorteil ist, damit hochpriore Tasks die niederprioren unterbrechen können und nicht durch diese ausgebremst werden. Prinzipiell kann man aber mit beiden Scheduling-Verfahren Echtzeitsoftware schreiben. >>> Schlimmer noch: wenn's mit dem Speicher eng wird, können aus 20ms auch >>> leicht mal 200 oder 2000ms werden... >> >> Mit Linux und PREEMT_RT-Kernel bekommt man je nach Rechner auch 30 µs >> zuverlässig hin. > > 30µs?! Für Userspace-Tasks? Das mußt du mir zeigen. Da musst du auf die OSADL-Homepage gehen. Die testen dort alle möglichen Rechner auf ihre Echtzeitfähigkeit mit PREEMPT_RT. Hier mal ein wahlfrei rausgegriffenes Beispiel, wo das Maximum bei 33 µs lag: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s0.0.html?latencies=&showno=&shadow=0&slider=171 > Ich sage: Entweder begreifst du nicht, was der RT-Kernel tut (bist also > einfach nur doof, das wäre immerhin verzeihlich) oder du LÜGST wider > besseren Wissens. Das allerdings wäre unverzeihlich... Und du schaffst es mal wieder wie immer nicht, die Beleidigungen wegzulassen. Das wäre nicht mal verzeihlich, wenn du wüsstest, wovon du sprichst, was du aber offenbar nicht tust. Es war schon richtig, als letztens in einem anderen Thread ein Moderator alle Postings, in denen du deinem Tourette-Syndrom mal wieder freien Lauf gelassen hast, einfach rigoros gelöscht hat. Ich hab ja die Hoffnung, dass du so doch noch irgendwann lernst, wie man mit anderen Menschen diskutiert.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.