Support Center
TCP vs. UDP
Inhaltsverzeichnis
UDP ist das gewählte Protokoll für den GigE Vision-Standard und wird von allen Ethernet-Kameras auf Basis von GigE Vision verwendet. UDP bietet hervorragende Streaming-Leistung, geringe Latenz, Multicast und insgesamt ein einfacheres Design als TCP. UDP ist ein verbindungsloses Protokoll, das vor Beginn der Datenübertragung keinen Handshake zwischen sendenden und empfangenden Geräten erfordert. Es bietet einen eher „hands-off“-Ansatz für das Senden von Daten, da keine Flusskontrolle oder Paketzuverlässigkeit integriert ist. TCP hingegen ist ein verbindungsorientiertes Protokoll, das eine Client-zu-Host-Verbindung herstellen muss. Es verfügt außerdem über integrierte Zuverlässigkeitsfunktionen wie Flusskontrolle, Paketneuübertragung und Paketzusammenführung. Im Allgemeinen wurde UDP mit Fokus auf Geschwindigkeit und Einfachheit entwickelt, ohne die zusätzlichen Funktionen von TCP, während TCP stärker auf Übertragungszuverlässigkeit ausgerichtet ist.
TCP und UDP auf einen Blick
| TCP | UDP | |
|---|---|---|
| Connection Design | Connection-oriented | Connectionless |
| Connection Handshake | Yes (SYN, SYN-ACK, ACK) | None. PC sends discovery packets to cameras on same subnet |
| Guaranteed Frame delivery | Yes | No |
| Transmission Method | Stream-oriented | Datagram |
| Data Retransmission | Yes (hardware layer) | Optional (requires filter driver) |
| Flow Control | Yes (hardware layer) | Optional - Inter-packet delay |
| Jumbo Frames | Yes | Yes |
| Receive Side Coalescing / Large Packet Coalescing | Yes | No |
| Multi-cast | No | Yes |
Warum UDP für den GigE Vision-Standard verwenden?
Als GigE Vision eingeführt wurde (2006), entschieden sich Kamerahersteller nicht nur wegen der effizienten Streaming-Leistung für UDP, sondern auch wegen der Einfachheit. UDP konnte schnell in den Standard integriert werden, und fehlende Zuverlässigkeitsfunktionen konnten auf UDP aufgesetzt werden, wobei diese Funktionen auf Anwendungsebene ausgeführt werden (softwarebasiert, unter Nutzung von CPU-Ressourcen auf dem Host-PC und der Kamera-Firmware). Diese Zuverlässigkeitsfunktionen waren für Kamerahersteller zudem optional, was die Implementierung noch einfacher machte, wenn Hersteller auf diese Funktionen verzichten wollten. Der GigE Vision-Standard ermöglicht Ethernet-Geräten die Kommunikation über UDP, indem er Mechanismen für Gerätesteuerung, Streaming, Erkennung und Funktionslisten definiert:
- Das GigE Vision Control Protocol (GVCP) definiert, wie GigE Vision-Anwendungen Geräte konfigurieren und die Kontrolle über sie herstellen können.
- Das GigE Vision Stream Protocol (GVSP) legt die verschiedenen Datentypen und Übertragungsmethoden fest, die zur Übertragung von Bildern von einer Kamera an einen PC verwendet werden, einschließlich einer optionalen Funktion zur Paketneuübertragung.
- Der GigE-Mechanismus zur Geräteerkennung definiert, wie Geräte in einem Netzwerk gefunden werden.
- Eine XML-Datei enthält die GenAPI-Beschreibung, die alle Kamerafunktionen definiert. Diese Beschreibung basiert auf dem GenICam-Standard.
Im Vergleich dazu ist TCP ein komplexeres Protokoll für die Implementierung in der Kamera und erfordert mehr Hardware-Ressourcen in der Kamera (größerer FPGA-Bereich, mehr On-Board-Speicher), da verpflichtende Funktionen wie die Paketneuübertragung auf Hardware-Ebene implementiert werden müssen. Die Wahl von UDP für GigE Vision gab Kameraherstellern letztlich mehr Flexibilität bei der Entwicklung ihrer Ethernet-Kameras.
Obwohl UDP gewählt wurde, war Kameraherstellern und Kunden bewusst, dass die Zuverlässigkeit der Datenübertragung nicht vollständig ignoriert werden konnte. Der GigE Vision-Standard enthält Abschnitte zu Zuverlässigkeitsfunktionen, die TCP ähneln. Diese optionalen Funktionen werden dem Header jedes Datenpakets hinzugefügt. Der GigE Vision-Standard enthält einen GVSP-Header mit Sequenzinformationen, der es ermöglicht, Pakete eines Frames in anderer Reihenfolge zu senden und nach der Übertragung wieder korrekt auszurichten. Der GVSP-Header ermöglicht außerdem die Paketneuübertragung, falls ein Paket verloren geht.
Herausforderungen von UDP für 10GigE-Kameras
Die aktuelle Implementierung von UDP für GigE Vision wurde mit Blick auf 1GigE-Bandbreite entwickelt. Wie bereits erwähnt, sind die in UDP fehlenden Zuverlässigkeitsfunktionen im GigE Vision-Standard auf Anwendungsebene integriert. Das bedeutet, dass jede verwendete Zuverlässigkeitsfunktion durch die verfügbaren CPU-Ressourcen des Hosts, die Qualität der Kamerasoftware und des Filtertreibers sowie die Robustheit der Kamera-Firmware bei der Verarbeitung zusätzlicher Funktionen begrenzt wird. Beispielsweise erfordert die Paketneuübertragung in GigE Vision bei vielen Kameraherstellern einen speziellen Softwaretreiber auf dem Host-PC, einen sogenannten Filtertreiber, um fehlende Pakete zu überwachen. Wenn der PC ein fehlendes Paket erkennt, sendet er eine Anforderung zur Neuübertragung an die Kamera. Die Kamera muss das Paket anschließend analysieren, was in der Regel in der Firmware der Kamera erfolgt, und dieses Paket aus dem Bildpuffer der Kamera abrufen. Die Kamera muss die normale Übertragung pausieren und das angeforderte Paket erneut senden. Wenn mehrere Pakete über den Frame verteilt fehlen, kann dies sowohl den PC als auch die Kamera belasten. Bei 1-Gigabit-Geschwindigkeiten sind jedoch ausreichend CPU- und Kameraressourcen verfügbar, um verworfene Pakete zu überwachen und erneut zu senden.
Beispiel dafür, wie der Host-PC Pakete in falscher Reihenfolge und verworfene Pakete verarbeitet. Die Datenübertragung wird durch den vom Kamerahersteller bereitgestellten Filtertreiber überwacht, da UDP keine integrierten Zuverlässigkeitsfunktionen bietet. Dieser Treiber liest den GVSP-Header jedes Pakets.
LUCID hat kontinuierlich daran gearbeitet, die UDP-Datenübertragung unter GigE Vision zu optimieren. Unser Filtertreiber bietet schnelle, latenzarme und CPU-optimierte Leistung sowie alle optionalen Zuverlässigkeitsfunktionen, die den Anwendern zur Verfügung stehen. Für die effizienteste Leistung sorgt die Installation des LUCID-Filtertreibers (LUCIDLwf.sys) für eine schnelle Paketüberwachung mit DMA-Paketübertragungen. Beim gleichzeitigen Streaming von vier Atlas10 10GigE-Kameras mit voller Bandbreite liegt die durchschnittliche CPU-Auslastung beispielsweise bei nur 8 %.
Betreiben Sie mehrere Atlas10 10GigE-Kameras mit optimierten CPU-Ressourcen dank LUCIDs UDP-Filtertreiber. PC-Spezifikationen finden Sie hier.
Bei einigen 10GigE-Anwendungen, insbesondere bei Anwendungen, bei denen Triggering für die vollständige Frame-Übertragung absolut entscheidend ist, kann die GigE Vision-UDP-Technologie jedoch an ihre Grenzen stoßen. Die enorme Zunahme der bei 10GigE gestreamten Daten kann zu Zuverlässigkeitsproblemen führen, insbesondere bei 10GigE-Mehrkamerasystemen mit nicht optimalen Host-PC-Spezifikationen (siehe unseren KB-Artikel „Beispiel-PC-Konfiguration für das Streaming mehrerer Atlas10-Kameras“). Da pro Kamera zehnmal mehr Daten überwacht werden müssen, können Host-PC und Kamera nach einem anfänglichen Problem, das eine Paketneuübertragung auslöst, überlastet werden. Dies führt dazu, dass Pakete verworfen werden, wenn die CPU zu beschäftigt ist, um den Datenstrom zu verarbeiten. Das Ergebnis sind beschädigte oder unvollständige Bilder. Mit zunehmender Bandbreite der Bildübertragung steigt die Wahrscheinlichkeit, dass weitere Pakete verloren gehen. Dadurch entsteht ein Teufelskreis, da die CPU-Auslastung weiter zunimmt, während weiterhin Paketneuübertragungen von der Kamera angefordert werden. Obwohl der GigE Vision-Standard Zuverlässigkeitsfunktionen auf UDP aufsetzt, kann die aktuelle Verwendung von UDP und Paketneuübertragung aufgrund ausgelasteter CPU-Ressourcen einen Dominoeffekt beschädigter Bilder verursachen.
Beispiele für beschädigte Bilder bei UDP-Übertragung. Schwarze Balken treten typischerweise zu Beginn eines Streams auf, wenn die Bildpuffer noch nicht verwendet wurden (a). Eine bewegte Szene mit verworfenen Paketen zeigt ein vorheriges Bild, da dies die letzten im Bildpuffer gespeicherten Pakete sind (b).
TCP-Zuverlässigkeit: beginnt mit einem Handshake
Im Vergleich zu UDP verfügt TCP über integrierte Zuverlässigkeitsfunktionen und ermöglicht Ethernet-Kameras, einschließlich 10GigE-Kameras, die vollständige Frame-Übertragung zu garantieren. Beachten Sie, dass dies nicht garantiert, dass jeder Frame übertragen wird. Es bedeutet, dass alle Pakete eines Frames (Bildes) übertragen werden. Mit anderen Worten: Eine Anwendung wird keine beschädigten oder unvollständigen Bilder erhalten (wie oben gezeigt), kann jedoch weiterhin verworfene Frames erleben, wenn kritische Fehler in der Verbindung oder auf dem Host-PC auftreten.
Die vollständige Frame-Übertragung ist wichtig für Anwendungen, die Kameratriggering für Inspektionen erfordern. In diesen Situationen ist es entscheidend, dass keine Pakete verloren gehen, da dies zu beschädigten Bildern führen kann, was wiederum Probleme wie OCR-Fehlinterpretationen oder schlechte Objekterkennung verursacht. Im Gegensatz zu UDP benötigt TCP keinen auf dem Host-PC installierten Filtertreiber und verwaltet die Paketneuübertragung sowie zusätzliche Zuverlässigkeitsfunktionen auf Hardware-Ebene, unter Nutzung der Netzwerkschnittstellenkarte (NIC) und des FPGAs der Kamera. Die Grundlage einer zuverlässigen Datenübertragung beginnt mit dem Drei-Wege-Handshake von TCP. Dieser Handshake erstellt eine TCP-Socket-Verbindung, reserviert Systemressourcen und legt die TCP-Fenstergröße (Puffer) für die Datenübertragung fest. Da Systemressourcen reserviert werden, muss die Verbindung auch beendet werden, bevor diese Ressourcen für andere Aufgaben verwendet werden können.
Im Gegensatz zu GVSP über UDP, bei dem GVSP-Header in alle Datenpakete eines Frames eingefügt werden, fügt GVSP über TCP den GVSP-Header nur einmal pro Frame ein. Dadurch wird der Overhead reduziert.
Der TCP-Handshake (SYN, SYN-ACK, ACK) mit der Atlas10 10GigE-Kamera stellt eine TCP-Socket-Verbindung her, reserviert Systemressourcen und legt die TCP-Fenstergröße (Puffer) für die Datenübertragung fest.
Sobald eine TCP-Verbindung zwischen Kamera und Host-PC hergestellt ist, kann die Anwendung von zuverlässigerer Paketübertragung, höheren Bildraten und konstant niedriger CPU-Auslastung profitieren. Diese drei Vorteile werden durch die folgenden TCP-Funktionen erreicht:
- TCP-Flusskontrolle und Windowing (Hardware-Ebene)
- Paketneuübertragung (Hardware-Ebene)
- Large Receive Offload (Linux) & Receive Side Coalescing (Windows) (beide auf Hardware-Ebene)
TCP-Flusskontrolle und Windowing
TCP-Flusskontrolle
Bei Verwendung von TCP muss die NIC ein Bestätigungspaket (ACK) an die Kamera zurücksenden, um zu bestätigen, dass eine bestimmte Datenmenge (in Bytes) erfolgreich empfangen wurde. Das ACK-Paket teilt der Kamera mit, wie viele Daten empfangen wurden, wie viele Daten sich auf der Leitung befinden (in Übertragung) und wie viel Platz im „Sliding Window“ verbleibt. ACKs helfen dabei, die Bildrate der Kamera festzulegen, indem sie die Kamera zwingen, zu pausieren und die Bildrate zu reduzieren, bis die richtigen ACKs empfangen wurden. Dies wird als Flusskontrolle bezeichnet und erhöht die Zuverlässigkeit der Paketübertragung, indem sich ansammelnde Pakete im TCP Sliding Window und im Bildpuffer der Kamera gespeichert werden, bis die NIC bereit ist. Dadurch können Kamera und Host-PC die Verbindungsqualität kontinuierlich auf Hardware-Ebene überwachen. Obwohl die NIC so eingestellt ist, dass sie nach Möglichkeit für jedes empfangene Paket ein ACK sendet, kann sie je nach Auslastung des Host-PCs ein ACK verzögern und für mehrere Pakete senden. Das Senden von ACKs erhöht zudem den Overhead nicht und belegt keine Bandbreite auf Kameraseite, da 10GigE Vollduplex ist.
Kamera-Flusskontrolle
In der Kamera fordert jeder Frame (jedes Bild) ein ACK vom Host-PC an, bevor der nächste Frame in das TCP Sliding Window ausgelagert werden kann. Wenn der Host-PC zu lange ausgelastet ist, füllt sich der 880-MB-On-Camera-Frame-Puffer der Atlas10 mit Frames, bis die Kamera schließlich Frames verwirft. Dies führt zu einer niedrigeren Bildrate und reduziert den Datenfluss, bis der PC bereit ist. Unvollständige Bilder mit fehlenden Daten werden jedoch niemals an den Host-PC gesendet. Das liegt daran, dass der letzte Frame im Frame-Puffer der Kamera gehalten wird, bis die Kamera alle Pakete des Frames gesendet und der Host-PC die entsprechende Anzahl von ACKs an die Kamera zurückgesendet hat. TCP-ACKs werden von der Kamera-Firmware nie gesehen, da sie im FPGA der Kamera und in der NIC des Host-PCs verarbeitet werden. Beachten Sie, dass LUCID die TCP-ACK-Frequenz auf 1 setzt, da dies die niedrigste Latenz ermöglicht (diese Einstellung ist nur unter Windows verfügbar).
TCP-Paketneuübertragung
Die TCP-Paketneuübertragung arbeitet zusammen mit der TCP-Flusskontrolle, da sie ACKs nutzt, um sicherzustellen, dass Pakete empfangen werden. Fehlt ein Paket auf dem Host-PC, sendet der Host drei ACKs mit derselben Bestätigungsnummer, um eine Paketneuübertragung auszulösen. Die Kamera sendet außerdem automatisch das letzte Paket erneut, wenn sie kein ACK erhält, bevor der „Retransmission Timer“ abläuft. Der Host kann beliebige Daten anfordern, die sich im TCP Window befinden. Da die Paketneuübertragung von der TCP-Hardware verwaltet wird, muss keine Bandbreitenreserve (DeviceLinkThroughputReserve) mehr für die GigE Vision-Paketneuübertragung festgelegt werden. Dadurch werden rund 10 % Bandbreite frei (LUCIDs Standardeinstellung bei Verwendung von UDP), und die Kamera kann höhere Bildraten erreichen* (*abhängig von der maximalen Bildrate des Sensors). Obwohl TCP weiterhin Bandbreite für die Paketneuübertragung benötigt, wird die Bandbreitenmenge dynamisch durch die TCP-Hardware angepasst, ohne dass der Benutzer einen statischen Wert festlegen muss.
Large Receive Offload (LRO) / Receive Side Coalescing (RSC)
Large Receive Offload (LRO, Linux) und Receive Side Coalescing (RSC, Windows) ermöglichen der NIC, kleinere Pakete zu größeren Segmenten zusammenzufassen, wodurch die Anzahl kleinerer Pakete reduziert wird, die von der CPU verarbeitet werden müssen. Wenn die NIC die Pakete empfängt, werden diese zunächst geprüft, ob sie zusammengefasst werden können (korrekte Reihenfolge, gültige CRC, passende TCP-Flags). Wenn dies möglich ist, wird der Header des ersten Pakets beibehalten, während die Header der folgenden Pakete entfernt werden. Dies wird für alle eingehenden Pakete bis zum Interrupt fortgesetzt (Interrupt Moderation). Die Paketzusammenführung fügt keine zusätzliche Latenz hinzu, da die NIC Pakete innerhalb der Interrupt-Moderationszeit zusammenfasst. Weniger, aber größere Segmente erzeugen einen effizienteren Stream. Das Konzept ähnelt dem Aktivieren von Jumbo Frames und Interrupt Moderation, die beide zur Reduzierung der CPU-Auslastung beitragen. (Siehe Tipps zum Erreichen der maximalen Bildrate). Paketzusammenführung ist bei UDP nicht möglich, da UDP definierte Anfänge und Enden für jedes Paket hat. Da TCP jedoch streambasiert ist, gibt es keine definierten Grenzen der Daten.
LRO und RSC führen zu einer geringeren CPU-Auslastung, insbesondere bei 10GigE-Mehrkameraanwendungen. Dadurch werden CPU-Ressourcen freigegeben, sodass sich die CPU auf andere Bildverarbeitungsaufgaben wie Objekterkennung oder Klassifizierung konzentrieren kann.
Oben: Die Atlas10-Kamera und die NIC sind auf 16k Jumbo Frames eingestellt, werden jedoch dank Large Receive Offload unter Linux von der NIC zu 30k-Frames (29928) zusammengefasst. Dadurch wird die Anzahl der Paketsegmente reduziert, die das System verarbeiten muss. Paketzusammenführung ist dank der streambasierten Arbeitsweise nur mit TCP möglich.
Oben: Vier Atlas10-Kameras streamen mit 10GigE unter Ubuntu 18.04. Ca. 2,2 % CPU-Auslastung während der Bildaufnahme ohne LRO.
Oben: Vier Atlas10-Kameras streamen mit 10GigE unter Ubuntu 18.04. Ca. 1,9 % CPU-Auslastung während der Bildaufnahme mit aktiviertem LRO.
Oben: Vier Atlas10-Kameras streamen mit 10GigE unter Windows 10. Ca. 13 % CPU-Auslastung während der Bildaufnahme ohne RSC.
Oben: Vier Atlas10-Kameras streamen mit 10GigE unter Windows 10. Ca. 11 % CPU-Auslastung während der Bildaufnahme mit aktiviertem RSC. (PC-Spezifikationen finden Sie hier.)
Fazit
LUCID unterstützt nun sowohl UDP (GigE Vision) als auch TCP-Protokolle für unsere Atlas10 10GigE-Kameras. Anwender können mithilfe unseres Arena Software Development Kits einfach zwischen den Protokollen wechseln. Während LUCIDs Filtertreiber UDP für schnelle, latenzarme Datenübertragung stark optimiert, möchten manche Anwender möglicherweise vor allem eine garantierte vollständige Frame-Übertragung priorisieren und daher TCP wählen. Wenn eine Anwendung unter einer UDP-Verbindung unter verworfenen Paketen oder hoher CPU-Auslastung leidet, kann TCP eine zuverlässigere Datenübertragung zwischen 10GigE-Kameras und dem Host-PC bieten. TCP-Flusskontrolle, Paketneuübertragung und LRO/RSC-Technologien ermöglichen Bildübertragungen mit hoher Bandbreite, die eine vollständige Frame-Übertragung garantieren, während sie vollständig auf Hardware-Ebene arbeiten. Dank LUCIDs proprietärem 10GigE-IP-Core auf den Atlas10-Kameras unterstützt LUCID nun TCP-Verbindungen zusätzlich zu herkömmlichem UDP und bietet Anwendern mehr Auswahl beim Aufbau einer zuverlässigen 10GigE-Vision-Anwendung.
Der Wechsel von UDP zu TCP ist in ArenaView einfach. Stoppen Sie einfach die Aufnahme, ändern Sie das Protokoll und starten Sie erneut.
