Auf einem PC habe ich ein Linux mit Preempt-RT-Patch, so das problemlos alle 35 Mikrosekunden Werte von Ports eingelesen werden können, aber im Netzwerk habe ich damit leider keine harte Echtzeit. Schon Pingen nach Localhost, mit ping -q -s 28 -l 1 -p 0f1e2d3c4b5a6978 -i 0.001 localhost zeigt nach einem Tag eine Worst-Case-Latenz von über 10 Millisekunden. Woher kommt das und kann man das abstellen, z. B. durch passende Parameter für den Kernel oder einige Module?
warum es bei Localhost nicht geht kann ich nicht sagen, aber normales Ethernet ist nicht für Harte Echtzeit gemacht. Wenn jemand anderer Datenüberträgt dann muss du halt warten. Es gibt dort keine Prio.
Der PC hat aber schon mehr als einen physikalischen Core?
Georg A. schrieb: > Der PC hat aber schon mehr als einen physikalischen Core? Ja, der PC ist ein Esprimo E9900 mit zwei Cores. Mit einem Messprogramm mit 6 Threads kann ich mit einer Worst-Case-Latenz von 35 µs die 13 Eigangspins vom Parallelport auslesen, beim Pingen mit nur einem Thread und nur nach localhost habe ich aber die dreihundertfache Worst-Case-Latenz. Schon nach fünf Minuten zeigt sich die dreizigfache.
:
Bearbeitet durch User
Vergiss einfach mal, an ein Etherent harte Echtzeitanforderungen zu stellen. Ethernet hatte andere Designgrundlagen. zB Autokonfiguration fuer optimale Wege, Reassembly for Packeten die verschiedene Wege gingen, Autoretry usw. allenfalls solltest du die Anforderungen ueberdenken. Was soll das Netzwerk denn koennen ? Zudem muss der Rechner auf der anderen Seite auch diese Anforderungen erfuellen.
:
Bearbeitet durch User
Ethernet + TCP/UDP/IP ist nicht echtzeitfähig, das ist einfach aufgrund des Protokoldesigns so. Besonders TCP ist da kritisch, da laut Definition die Anwortzeit für ein Aknowledge bis zu 500ms betragen kann. Oft kann man das durch die Verwendung von UDP aber etwas entschärfen. Richtig echtzeitfähig ist das aber auch nicht. Ist harte Echtzeit gefordert kommt man um einen geeigneten Industriebus nicht herum. Harte Echtzeit bekommmt man mit Bussen mit Tokenring Zugriffsverfahren hin (z.B. Profibus).
Sorry. Meinte mit Industriebus eigentlich eher den Begriff Feldbus.
Ich verstehe nicht ganz, was du damit erreichen möchtest? Warum sollte das Ethernet echtzeitfähig sein? Was soll damit bezweckt werden? Dann müßte die Gegenseite das ja auch sein. Und die Switche in der Mitte. Und auf dem Ethernet dürften nicht noch andere Pakete wie ARP, DNS etc laufen.
Erstaunlich ist aber schon, dass es auch über localhost nicht geht. Da ist kein Ethernet dazwischen. Sieht irgendwie so aus, als wäre ein anderer Thread wichtiger...
Georg A. schrieb: > Erstaunlich ist aber schon, dass es auch über localhost nicht geht. Da > ist kein Ethernet dazwischen. Sieht irgendwie so aus, als wäre ein > anderer Thread wichtiger... Ja, aber auf dem Rechner läuft sonst praktisch nichts, kein GUI, da ist nur ein lokaler User und Test-Programme wie Cyclictest zeigen eine Worst-Case-Latenz von 35 Mikrosekunden. Das Pingen nach localhost, von root, zeigt über 10.000.
Wenn man ein tagged VLAN verwendet kann man Prioritäten vergeben. Das macht die ganze Sache schonmal viel besser.
Auch wenns nur über localhost rausgeht wird ein ICMP Paket erzeugt, über eine virtuelle Schnittstelle "versendet", empfangen, verarbeitet und beantwortet, mit der Antwort passiert das selbe. Da sind einige Context-Wechsel involviert. Da es keinen Grund gibt, dass so eine Operation irgendwelche Deadlines einhalten muss, ist da sicher auch nichts dahingehend optimiert. Über reales Ethernet bekommt man ohne Klimmzüge eventuell einige wenige ms als worst-case-Latenz hin, passenden Switch einsetzen (oder gleich einsparen, direkt verbinden), und schaun, dass sonst kein Verkehr auf der selben Leitung ist. Sende- und Empfangspuffer abdrehn soweit möglich. Beim Protokoll muss man auch aufpassen, TCP ist eher ungeeignet, weil man da keine richtige Kontrolle hat, wann das Betriebssystem ein Paket macht, und auch der Sendezeitpunkt u.U. verzögert wird, um größere Pakete und damit höheren Durchsatz zu erzielen. Also UDP. Oder gleich ganz "zu Fuss" nackerte IP-Pakete. Für "richtig" gibts dann profinet mit eigener Hardware.
Inzwischen zeigte sich das man, wie bei cyclictest, die Echtzeitpriorität setzen muss, mit chrt. In einem Skript am Anfang ionice -c3 -p $$ renice +19 -p $$ chrt -f -p 99 $$ funktioniert das Pingen, auf einem älteren embedded PC, mit einem Worst-Case-Wert von 280 Mikrosekunden, rund dem doppelten des mit Cyclictest gemessenen Werts.
Magst du nicht begreifen wollen das TCP/IP NICHT echtzeitfähig ist?! Auch wenn deine Worst-Case-Latenz nun bei 280µs liegt, was übrigens sehr beeindruckend ist, kannst du nicht davon ausgehen das der selbe Ping unter genau den gleichen Umständen beim zweiten mal auf z.b. 520µs oder 4ms springt. Es geht einfach nicht. Solltest du wirklich eine Echtzeitfähige Verbindung benötigen, musst du auf eine Serielle Datenübertragung (Wie oben schon gesagt, RS oder Feldbus etc..) umsteigen, dort kannst du dies ohne jegliche Probleme bewerkstelligen. Oder du nimmst als Referenzwert für deine Timebase und Frametime die max. definierte TimeOut des TCP/IP an (im Default 500ms). Anders wirst du da nie glücklich werden.
MaWin schrieb: > https://en.wikipedia.org/wiki/PROFINET Auch das hat bei TCP/IP laut Specifiation "...with reaction times in the range of 100 ms...". Auch mit RT und IRT: "...up to 1 ms cycle times..." Für mich sieht Realtime halt anders aus... mit Begriffen wie "in range of" oder "up to" kann ich da halt nichts anfangen. Entweder fest 100ms oder fest 1ms... das sind Werte mit denen man rechnen kann. Realtime |= Schnellst als möglich!
Ich würde mal sagen: Nur wenn Du alles in der Hand hast, kannst Du einen auf Echtzeit machen. Aber spätesten, wenn dies nicht mehr der Fall ist, geht das nicht mehr. Selbst bei einer einfachen, seriellen Kommunikation, kannst Du nur dann eine Reaktionszeit definieren, wenn Dein Gegenüber nichts zutun hat. Wie aber soll das denn gehen, wenn weder Dein Gegenüber, noch die Schnittstelle dazu in der Lage sind? Im übrigen sollte jedem, der schon öfters mal über das Netz kommuniziert hat, klar sein, dass unabhängig von der Rechnerei manchmal Daten Ruck-zuck übertragen werden und ein anderes mal quälend langsam. Der einfache Grund hierfür ist der: Du bist nicht allein! Also hast Du nicht alles in der Hand. Es würde mich nicht wundern, wenn auf Deiner eigenen Strecke, wo kein anderer Sendet, ein recht großer Zeitbereich als Reaktionszeit definiert werden müsste. Aus dem einfachen Grunde weil das Medium nicht dafür definiert wurde.
DraconiX schrieb: > Magst du nicht begreifen wollen das TCP/IP NICHT echtzeitfähig ist?! Thema verfehlt: Das gewöhnliche Ping verwendet ICMP. Daneben ist auch klar das man im echten Netzwerk eine echtzeitfähige Gegenstele braucht und auch Aspekte wie Packet-Loss und Signallaufzeit berücksichtigt werden müssen. Aber für Localhost eignet sich Ping durchaus für eine grobe Latenzmessung, die man mit Tools wie Cyclictest besser hinbekommt.
Erwin M. schrieb: > Thema verfehlt: Das gewöhnliche Ping verwendet ICMP. Thema verfehlt: ICMP wird in einem Standart IP Package gekapselt.
Dass Ethernet keine Echtzeitbedingungen garantieren kann wurde schon ausgiebig erwähnt. Allerdings kann das reale Verhalten vielleicht getuned werden. Ein Teil des Stacks ist heutzutage oft in das Ethernet-Interface ausgelagert. Das Zeitverhalten davon könnte eine Rolle spielen, und das dürfte eher auf Durchsatz optimiert sein. Parameter vom Interface könnten das ändern.
:
Bearbeitet durch User
Schade das hier die Begriffe so wild durcheinander gewürfelt werden. 1.) Ethernet/das MAC Layer ist nicht echtzeitfähig. Hauptsächlich wegen Kollisionen (bei <1Gbit wird noch Kollisionserkennung wie beim alten 10Base2 gemacht) und Switches, die Pakete in beliebiger Reihenfolge sortieren und weiterverteilen. Mit Crossover und 2 direkt verbundenen PCs mit Gigabit kann man das Verhalten dramatisch verbessern. 2.) IP ist nicht echtzeitfähig, u.a. wegen Routing, Broadcasts, Puffern etc. Über welches Medium (Funk, DSL, Ethernet )das passiert spielt keinerlei Rolle. Schwankende Latenzen kann man durch geeignete Maßnahmen reduzieren, z.B. MAC-IP-Zuordnungen statisch, Queues kürzen, Prioritäten setzen etc. 3.) UDP und TCP sind ebenfalls nicht echtzeitfähig. Was den Fall localhost-ping angeht: Das ICMP-Paket muss auch dabei durch den IP-Stack der diverse queues hat. Siehe 2.)... Ansonsten: 3x0=0. Keine der Komponenten kann es, wen wundert also das es nicht geht.
LOL schrieb: > Schade das hier die Begriffe so wild durcheinander gewürfelt werden. > > 1.) Ethernet/das MAC Layer ist nicht echtzeitfähig. > ... > 2.) IP ist nicht echtzeitfähig, u.a. wegen Routing, Broadcasts, Puffern > etc. > ... > 3.) UDP und TCP sind ebenfalls nicht echtzeitfähig. Im LAN stimmt das generell, aber auch für Ethernet gibt es Echtzeit-Protokolle. Und bei Localhost ist ja überhaupt kein Ethernet beteiligt; localhost ist schneller als Infiniband, Omnipath ...
Erwin M. schrieb: > Und bei Localhost ist ja überhaupt kein Ethernet beteiligt Naja doch, wie kommst du denn zu der Vermutung? Localhost bzw. 127.0.0.1 bzw ::1 ist ein Loopback-Device. Es verhält sich ganz genauso wie eine ein anderer IP Bereich, nur das er über eine Virtual-NIC wieder zurück an den eigenen Host geschickt wird. Ethernet ist da natürlich beteiligt, wenn auch virtuell.
Rene K. schrieb: > Erwin M. schrieb: >> Und bei Localhost ist ja überhaupt kein Ethernet beteiligt > > Naja doch, wie kommst du denn zu der Vermutung? Localhost bzw. 127.0.0.1 > bzw ::1 ist ein Loopback-Device. Es verhält sich ganz genauso wie eine > ein anderer IP Bereich, nur das er über eine Virtual-NIC wieder zurück > an den eigenen Host geschickt wird. Ethernet ist da natürlich beteiligt, > wenn auch virtuell. Nö. Du bist wohl zu jung, dass Du noch nie andere Netzwerkstandards kennen gelernt hast: Token Ring, ArcNet, FDDI. Viele Feinheiten siehst Du daher nicht. Auch, dass loopback keine Abhängigkeiten zu Ethernet hat. Oder siehst Du da eine Ethernet-Adresse? Oder schau Dir mal die MTU von lo an. lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 Eine MTU von 16436 Bytes kann kein Ethernet. Selbst mit Jumbo Packets sind es da nur 9000 Bytes. Also: 6. Setzen. fchk
Erwin M. schrieb: > Im LAN stimmt das generell, aber auch für Ethernet gibt es > Echtzeit-Protokolle. Brauchen die dann spezielle Switches oder wie geht das? Die Switches adressieren ja Quell/Ziel MACs zu Ports, und das dürfte u.U. zu schwankenden Latenzen führen. Oder reicht es einfach auf cut-through umzuschalten? Erwin M. schrieb: > Und bei Localhost ist ja überhaupt kein Ethernet beteiligt; localhost > ist schneller als Infiniband, Omnipath ... Aber IP schon, deswegen schrieb ich ja "Siehe 2.)" Und da der Stack im Weg ist geht es halt nicht so. Frank K. schrieb: > Eine MTU von 16436 Bytes kann kein Ethernet. Selbst mit Jumbo Packets > sind es da nur 9000 Bytes. Jain. Einige Hersteller bieten bis 16k, "normal" sind aber ca. 9k (billige (Realtek) NICs meist nur 7k). JumboFrames sind halt ne nicht standardisierte Erweiterung. Ansonsten FullAck zum Inhalt des restlichen Beitrags, wenn auch nicht zwingend zur Art und Weise.
Frank K. schrieb: > kennen gelernt hast: Token Ring, ArcNet, FDDI. Viele Feinheiten siehst In Maschinensteuerungen kann man auch heute noch ArcNet finden.
LOL schrieb: > schwankenden Latenzen Schwankende Latenzen mögen in mancher Anwendung stören, sind aber nicht das Kriterium von Echtzeitfähigkeit. Sondern eine garantierte und zur Aufgabe passende Obergrenze der Latenz. Nur kann man dafür nicht einfach in den Laden gehen und den nächstbesten Billigswitch mitnehmen. Sondern muss sich eben in der gesamten Vernetzung um das Thema kümmern. Priorisierung und Puffersteuerung kann man auch in Ethernet-Switches finden. VLAN tagging wurde oben schon erwähnt, und das damit mögliche Prioritätsfeld vergrösserte wiederum den Buchstabensalat hinter IEEE 802.1.
:
Bearbeitet durch User
LOL schrieb: > JumboFrames sind halt ne nicht standardisierte Erweiterung. ... und sind ohnehin eher Schnee von gestern. Die Probleme, die man sich damit einhandeln kann, übersteigen den kaum noch vorhandenen Nutzen bei weitem. Der Nutzen lag in ein paar Prozent mehr Durchsatz und drastisch reduzierter Interrupt-Last. Jumbo Frames haben sich mittlerweile durch intelligente Adapter weitgehend erledigt. Zwischen System und Ethernet-Controller wird heute z.B. mit 64KB Brocken gearbeitet, die der sendende Adapter zerlegt und der empfangende wieder zusammensetzt. Die Checksums der IP Protokolle erledigt der nebenbei auch.
:
Bearbeitet durch User
A. K. schrieb: > Jumbo Frames haben sich mittlerweile durch intelligente Adapter > weitgehend erledigt. Zwischen System und Ethernet-Controller wird heute Das möchte ich doch zumindest anzweifeln: Soweit mir bekannt, sind seit Erfindung von 10Gb-Ethernet Jumbo Frames aktueller denn je. Bei 10GBase oder schneller sind Jumbo Frames extrem nützlich, da sie den Overhead massiv reduzieren und sie wirken sich deshalb sogar positiv auf Latenzen aus. Natürlich sind wir dann hier im Serverbereich, bei dem man Hops und Infrastruktur unter Kontrolle hat... Wenn man z.B. Netzwerkspeicher für Virtualisierungzwecke anbinden (z.B. iSCSI) oder redundant aufbauen will (SAN-Synchro, Raid-over-Ethernet, FCoE) kommt man um Jumbo Frames quasi nicht herum wenn man die maximale Leistung nutzen will. Alternativ kann man in sündhaft teure Spezialhardware (FC & Co.) investieren, welche im Wesentlichen ein 1-trick-pony darstellt. Massenspeicher arbeitet am liebsten in 4kiB (Dateisystem-Sektorgröße) oder 8kiB (z.B. Datenanken) Transfers das eigentliche Übertragungsprotokoll kommt noch dazu. Da wird 10GBase extrem ineffizient, wenn man alles in 1500Byte Pakete aufteilen muss, egal wie gut die Hardware ist. Selbst bei 1GBase-T sind Jumbo Frames in diesem Anwendungsfall schon anzuraten. Da mittlerweile die Brückenstandards laut NBase-T (2,5 und 5Gbit) auf den Markt gelassen wurden, gehe ich davon aus das sich Jumbo Frames in diesem Bereich eher noch verbreiten. > z.B. mit 64KB Brocken gearbeitet, die der sendende Adapter zerlegt und > der empfangende wieder zusammensetzt. Die Checksums der IP Protokolle > erledigt der nebenbei auch. Die diversen "Offloading"-Verfahren haben aber wieder Auswirkungen auf die Latenz und auch sonst nicht nur Vorteile, weil die queues wieder länger werden. Zudem wird dann mit solchen Adaptern jede Technik schwierig bis unmöglich, die auf TCP/UDP Rahmen direkt zugreifen muss oder mit Ethernet bzw. IP-Frames arbeitet (Bridging, Bonding, ...). Problemdiagnose ist in dem Falle auch eher schwierig, weswegen z.B. Wireshark solche Verfahren komplett deaktiviert.
LOL schrieb: > Da wird 10GBase extrem > ineffizient, wenn man alles in 1500Byte Pakete aufteilen muss, egal wie > gut die Hardware ist. Da die verwendeten Adapter das regelmässig selbst durchführen, arbeitet die Vernetzung auf der Ebene der Server/NAS/... aus Sicht der Prozessoren und Betriebssysteme quasi mit 64KB Frames, unabhängig davon, ob das Netzwerk selbst mit 1,5K oder 9K Frames arbeitet. So lange der Adapter das schafft, und dafür ist der konzipiert, besteht also hinsichtlich der Effizienz kein Unterschied. Ebenso sind bessere Switches in der Lage, mit 1,5K Frames den vollen Durchsatz zu erzielen. Unterschiede gibts da höchstens bei Frames von Minimalgrösse. Umgekehrt sorgt ein Verzicht auf Offloading für höhere CPU/Interrupt-Last in den beteiligten Systemen, reduziert also die Effizienz. > Zudem wird dann mit solchen Adaptern jede Technik > schwierig bis unmöglich, die auf TCP/UDP Rahmen direkt zugreifen muss > oder mit Ethernet bzw. IP-Frames arbeitet (Bridging, Bonding, ...). Findet routinemässig statt, Bonding eingeschlossen. Offloading findet in Servern und in Clients schon lange statt, und zwar als Standardeinstellung auch in Desktop-Adaptern. Ich weiss nicht ob bei allen, jedenfalls aber bei Intel und Broadcom. > Problemdiagnose ist in dem Falle auch eher schwierig, weswegen z.B. > Wireshark solche Verfahren komplett deaktiviert. Ich hatte vor ungefähr einem Jahrzehnt mal einen Anwendungsfall, in dem Offloading in den Standard-PCs abgeschaltet werden musste, weil eine ganz bestimmte Anwendung damit nicht funktionierte. Die exakte Ursache konnte nicht geklärt werden, denn dafür wäre eine teure Kooperation mit den Entwicklern der Anwendung nötig gewesen. Zumindest damals hatte Wireshark (oder wie auch immer das Teil damals hiess) angezeigt, was im Netzwerk auch normalerweise abging. Andernfalls hätte ich das Problem darin nicht sehen können. Es ist kein Vorteil, wenn ein Werkzeug zur Fehlersuche die Situation signifikant verändert und damit möglicherweise die Fehlersuche behindert. > Wenn man z.B. Netzwerkspeicher für Virtualisierungzwecke anbinden (z.B. > iSCSI) oder redundant aufbauen will (SAN-Synchro, Raid-over-Ethernet, > FCoE) kommt man um Jumbo Frames quasi nicht herum wenn man die maximale > Leistung nutzen will. Ich erspare mir bei uns lieber die paar Prozent maximal möglichen Durchsatzes, zu Gunsten einer einfacheren und weniger anfälligen Netzstruktur. Ist übrigens nicht nur meine Ansicht, im Gespräch mit Netzwerkexperten von Anbietern ergab sich ein ähnliches Bild. PS: Ich hatte weiter oben bereits darauf hingewiesen, dass diese Funktionalität im Echtzeitfall möglicherweise hinderlich sein kann.
:
Bearbeitet durch User
DraconiX schrieb: > Auch das hat bei TCP/IP laut Specifiation "...with reaction times in the > range of 100 ms...". Auch mit RT und IRT: "...up to 1 ms cycle times..." Und? DraconiX schrieb: > Für mich sieht Realtime halt anders aus... mit Begriffen wie "in range > of" oder "up to" kann ich da halt nichts anfangen. "Up to" heißt auch "kann maximal". DraconiX schrieb: > Entweder fest 100ms > oder fest 1ms... Tut es auch. Zusätzlich einstellbar auch jeden anderen Wert, der durch "in range" oder "up to" abgedeckt wird. Ansonsten scheinen hier an einigen die letzten 10 Jahre Entwicklung in der industriellen Kommunikation vorübergegangen zu sein, mit TSN auch IEEE 802-Konform. Aber Zykluszeiten von 100µs realisiert man auch nicht in Software auf einem PC.
Also die allermeisten Anwendungen lassen sich auch ohne echtzeitfähigkeit vom Ethernetnetzwerk realisieren. Man denke nur mal an Audio- oder Videostreaming. Es ist zwar wegen den Caches etwas verzögert, aber die Samplingraten werden exakt eingehalten und das sogar über das weite Internet.
Johnny B. schrieb: > Also die allermeisten Anwendungen lassen sich auch ohne > echtzeitfähigkeit vom Ethernetnetzwerk realisieren. Das kann man so einfach nicht sagen. Egal wie man es dreht und wendet - Echtzeitfähigkeit ist eine Definitionsfrage. Wenn für dich 20 Stunden echtzeitfähig ausreichend sind -> OK. Es soll auch Aufgaben geben in denen 1us nicht ausreichend ist um echtzeitfähig zu sein. Wenn unbedingt Ethernet sein muss, dann muss man eben mit den Einschränkungen leben. Es gibt genügend Verbesserungen (EtherCAT, ...). Wenn die Einschränkungen nicht akzeptabel sind, muss man ein anderes System wählen. Um über 5km mit 10Gbit/s Daten zu übertragen nutzt auch niemand UART ... geht halt einfach nicht.
m.W. sind Infiniband bzw. Myrinet (von Myricom) deutlich schneller was die Latenzen angeht als Ethernet Wiki: "InfiniBand benutzt einen bidirektionalen seriellen Bus zur kostengünstigen und latenzarmen Datenübertragung (unter 2 Mikrosekunden)" Vielleicht mal etwas alten Kram davon aus der Bucht fischen und damit probieren.
Johnny B. schrieb: > Also die allermeisten Anwendungen lassen sich auch ohne > echtzeitfähigkeit vom Ethernetnetzwerk realisieren. Man denke nur mal an > Audio- oder Videostreaming. > Es ist zwar wegen den Caches etwas > verzögert, aber die Samplingraten werden exakt eingehalten und das sogar > über das weite Internet. Für eine Regelung ist ein Cache mit unbestimmter Latenz unbrauchbar... Für einen, der Video über Netzwerk schaut, ist es unerheblich, wie 'exakt' die Samplingrate ist. Aber wenn ich z.B. mehrere weit voneinander entfernte Messungen auf die Nanosekunde genau zeitgleich starten will, geht das über Internet garantiert in die Hose.
Paulaner schrieb: > Aber wenn ich z.B. mehrere weit voneinander entfernte Messungen auf die > Nanosekunde genau zeitgleich starten will, geht das über Internet > garantiert in die Hose. Synchronität hat nichts mit Echtzeit oder latenz zu tun. So lange beide die gleiche Zeitbasis haben (z.B. über GPS oder PTP), kann man auch über normales Ethernet oder gar Internet Dinge synchronisieren.
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.