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!
Gast
#4435051
Mit den nicht garantierbaren Latenzzeiten.
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.
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.
Es gibt spezielle Versionen von Ethernet, die durchaus echtzeitfähig (genug) sind, z.B. EtherCat u.a.
achso, jetzt ist es klar) vielen Dank! wäre dieses Echtzeitproblem z.B. durch Einsetzten eines Switch minimiert bzw behoben?
Ein Echtzeitfähiges Protokoll garantiert dir, dass mindestens X bit in y Zeit übertragen werden.
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.
Alex S. schrieb: > achso, jetzt ist es klar) vielen Dank! > > wäre dieses Echtzeitproblem z.B. durch Einsetzten eines Switch minimiert > bzw behoben? Nein.
super, vielen Dank euch für die Aufklärung!
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 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.
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.
Gast
#4435189
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.
Gast
#4435291
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.
Gast
#4435295
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.
Gast
#4435356
PTP wäre da noch interessant... http://www.xilinx.com/publications/prod_mktg/applications/sonys-ip-live-production-technology.pdf
Gast
#4435503
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.