TCP/IP Echtzeitfähigkeit

[Florian S. (sirius7)]

Hallo,

bekomme überall zu lesen, dass TCP/IP Protokol generell Echtzeitunfähig 
ist, sowie Ethernet an sich.

stimmt das auch wirklich? und, wenn ja, womit hat das eigentlich zu tun?

vielen Dank!

[Der Andere (Gast)]

Mit den nicht garantierbaren Latenzzeiten.

[Cyblord -. (cyblord)]

Echtzeit bedeutet du setzt dir ein Zeitlimit und kannst nun garantieren 
dass ein Befehl oder eine Antwort innerhalb dieses Zeitlimits bei dir 
oder einer Gegenstelle ankommen.

Bei Ethernet könnte theoretisch jeder Teilnehmer das Netz derart 
zustopfen, dass du ein solches Zeitlimit nicht garantieren kannst.

[Der E. (rogie)]

Das hat damit zu tun, dass es bei TCP/IP keine garantierten 
Antwortzeiten gibt. Wenn z.B. zwei Teilnehmer gleichzeitig senden, dann 
gibt es eine Kollision. Daraufhin wiederholen die Teilnehmer nach einer 
jeweils zufälligen Zeit den Sendeversuch.

[Frank E. (Firma: Q3) (qualidat)]

Es gibt spezielle Versionen von Ethernet, die durchaus echtzeitfähig 
(genug) sind, z.B. EtherCat u.a.

[Florian S. (sirius7)]

achso, jetzt ist es klar) vielen Dank!

wäre dieses Echtzeitproblem z.B. durch Einsetzten eines Switch minimiert 
bzw behoben?

[Frank E. (Firma: Q3) (qualidat)]

http://www.real-time-ethernet.de/

[Dennis R. (dennis_r93)]

Ein Echtzeitfähiges Protokoll garantiert dir, dass mindestens X bit in y 
Zeit übertragen werden.

[Cyblord -. (cyblord)]

Frank E. schrieb:
> Es gibt spezielle Versionen von Ethernet, die durchaus echtzeitfähig
> (genug) sind, z.B. EtherCat u.a.

Die Frage bezog sich allerdings auf TCP/IP. Und diese speziellen 
Versionen setzen natürlich voraus, dass keine "bösen" Teilnehmer auf 
demselben Ethernet arbeiten.

[Der E. (rogie)]

Alex S. schrieb:
> achso, jetzt ist es klar) vielen Dank!
>
> wäre dieses Echtzeitproblem z.B. durch Einsetzten eines Switch minimiert
> bzw behoben?

Nein.

[Florian S. (sirius7)]

super, vielen Dank euch für die Aufklärung!

[Frank E. (Firma: Q3) (qualidat)]

Cyblord -. schrieb:

> Die Frage bezog sich allerdings auf TCP/IP. Und diese speziellen
> Versionen setzen natürlich voraus, dass keine "bösen" Teilnehmer auf
> demselben Ethernet arbeiten.

Wenn das Ethernet als "umhüllendes" Transportprotokoll echtzeitfähig 
sein kann (durch entsprechende Vorkehrungen an Bus und Hardware), ist es 
das damit transportierte TCP am Ende eigentlich auch, es "erbt" damit 
gewissermaßen diese Fähigkeit.

[Frank M. (ukw) (Moderator)]

Frank E. schrieb:
> Wenn das Ethernet als "umhüllendes" Transportprotokoll echtzeitfähig
> sein kann (durch entsprechende Vorkehrungen an Bus und Hardware), ist es
> das damit transportierte TCP am Ende eigentlich auch, es "erbt" damit
> gewissermaßen diese Fähigkeit.

Da wäre ich mir speziell bei TCP nicht sicher. Denn Du brauchst als 
Sender noch ein ACK vom Empfänger. Weißt Du, ob dieser auch 
echtzeitfähig ist?

Bei UDP ist es anders: Raus und wech.

[Won K. (Firma: Outside the Asylum) (the_sane)]

Frank E. schrieb:
> ist es das damit transportierte TCP am Ende eigentlich auch, es "erbt"
> damit gewissermaßen diese Fähigkeit.

TCP/IP ist aber nicht an Ethernet gebunden und sobald das Medium 
wechselt ist es vorbei mit der möglichen Echtzeit.

[Stefan F. (Gast)]

Ich denke, TCP ist nicht Echtzeit fähig, weil es weder für die Nutzdaten 
noch für die Acknowledges eine definierte Übertragungszeit festlegt. Von 
Fehlerkorrektur mal ganz zu schweigen.

Ein Datenpaket kann durchaus mehrere Minuten dauern - auch wenn 
zweistellige Millisekunden der Regelfall sind.

[Noch einer (Gast)]

Grundidee vom TCP ist ja gerade, es soll so oft wiederholen, bis eine 
Empfangsbestätigung zurück kommt - es soll gar nicht Echtzeitfähig sein. 
Es soll auf unzuverlässigen Verbindungen zuverlässig Daten übertragen. 
Ganz egal, wie lang es dauert.

Grundidee beim IP. Es soll beim Ausfall eines Gateways irgendeinen 
anderen Weg suchen. Ganz egal, wie lange der Transport über die Umwege 
dauert.

Damit TCP/IP Echtzeitfähig wird, musst du ausgerechnet die Features 
aufgeben, für die TCP/IP konzipiert wurde.

[netzwerker (Gast)]

Kann man ja im RFC nachsehen:
https://www.rfc-editor.org/rfc/rfc793.txt
Da es mehrere Layer gibt und es nicht eine garantierte Laufzeit hat ist 
es nicht Echtzeit, dafür gibt's ja Industriebusse.

[Bernd N (Gast)]

PTP wäre da noch interessant...

http://www.xilinx.com/publications/prod_mktg/applications/sonys-ip-live-production-technology.pdf

[Noch einer (Gast)]

Wer nicht das ganze PTP Dokument durcharbeiten will: Kapitel 2.2 fasst 
die Unterschiede zwischen TCP/IP und Echtzeit-Netzwerk zusammen.

- Anwendungsprogramme reservieren Bandbreite, unabhängig davon, ob sie 
diese Bandbreite auch nutzen. (Alle Sender müssen exakt synchronisiert 
werden).

- Damit fehlerhafte Pakete nicht wiederholt werden müssen, werden 
zusätzliche Daten zur Fehlerkorrektur mit gesendet.

- Bei Ausfall einer Übertragungsstrecke wird nicht irgendeine verfügbare 
genutzt. Für Ausfälle werden zusätzliche Übertragungsstrecken bereit 
gehalten.

Letztendlich genau die Punkte, die wir bei einem weltweiten Netz mit 
beschränkter Leitungskapazität unbedingt vermeiden wollen.