mikrocontroller.net

Forum: PC-Programmierung Mit Linux Echtzeit-Kernel keine Echtzeit im Netzwerk


Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der PC hat aber schon mehr als einen physikalischen Core?

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sabberalot W. (jetztnicht)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Decius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Decius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry. Meinte mit Industriebus eigentlich eher den Begriff Feldbus.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: cri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man ein tagged VLAN verwendet kann man Prioritäten vergeben. Das 
macht die ganze Sache schonmal viel besser.

Autor: rmu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DraconiX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: DraconiX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sebastian S. (amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene K. (xdraconix)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Thema verfehlt: Das gewöhnliche Ping verwendet ICMP.

Thema verfehlt: ICMP wird in einem Standart IP Package gekapselt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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 ...

Autor: Rene K. (xdraconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> kennen gelernt hast: Token Ring, ArcNet, FDDI. Viele Feinheiten siehst

In Maschinensteuerungen kann man auch heute noch ArcNet finden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: vn nn (wefwef_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mike B. (Firma: Buchhaltung+Controlling) (mike_b97) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paulaner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.