UDP Geschwindigkeit

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • UDP Geschwindigkeit

    Hallo an die Netzterkkenner!

    Ich übertrage Daten von einer lokalen Anwendung zu anderen lokalen Anwendung über ein sendto() und UDP.
    Das funktioniert echt prima. Nur bei der Geschwindigkeit ergeben sich fragwürdige Symptome:

    Auf der Empfangsseite können rund 200.000 Messages zu je 1 KiloByte pro Sekunde empfangen werden. Das hab ich gemessen.
    Auf der Sendeseite lassen sich aber nur 2.000 Messages abschicken. Egal was ich mache. Mehr ist mit nicht drin.

    Wenn ich jedoch die selbe Anwendung zweimal gleichzeitig laufen lasse dann ergibt sich auch eine Verdoppelung der Gesamtsendeleistung.
    Es scheint so, als wäre die Übertragung pro Anwendung irgendwie limitiert obwohl die Übertragung insgesamt eigentlich schneller wäre.

    Weiß vielleicht jemand Bescheid warum das so ist und ob man das irgendwie konfigurieren kann ?

    Danke und Gruß
    Thomas

  • Nein, Fehlermeldungen gibts dabei keine. Weder auf der Sendeseite noch auf der Empfangsseite.
    Ist keine Spielerei sondern ein Programmpaket, dass größere Mengen Daten austauschen muss.

    Das mit der Anzahl der Nachrichten ist leider technisch bedingt. Mehr als 1500 Byte gehen nicht durchs MTU und wenn man mehr macht wird fragmentiert. Hab ich auch probiert, bringt aber nix. Beim Mac ist max 9216 Byte als Message-payload möglich. Ist nicht schneller als mit 1024.

  • @Thallius: Ich habs zuvor mit TCP gemacht. Ist ja kaum ein Unterschied im Code. Das verlangte aber nach jedem send eine sofortige Antwort, was die Sache nur unschön und langsam macht. Zudem ist es lokal gar nicht nötig. Da geht nix verloren und alles behält seine Reihenfolge. Wenn es lokal mit UDP klappt und remote Probleme auftreten, dann kann ich immer noch auf TCP erweitern.

  • Ich trau' mich kaum, zu fragen - weil Du daran bestimmt als erstes gedacht hast - aber trotzdem "zur Sicherheit": Du hast nicht zufällig aus alten Tests o. ä. eine Art Network Throttling auf Deine Rechner aktiv? Ich denk' da an Network Line Conditioner oder eher etwas, das auf Applikations-Ebene wirkt...

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Thomas schrieb:

    @Thallius: Ich habs zuvor mit TCP gemacht. Ist ja kaum ein Unterschied im Code. Das verlangte aber nach jedem send eine sofortige Antwort, was die Sache nur unschön und langsam macht. Zudem ist es lokal gar nicht nötig. Da geht nix verloren und alles behält seine Reihenfolge. Wenn es lokal mit UDP klappt und remote Probleme auftreten, dann kann ich immer noch auf TCP erweitern.
    Auch wenn ich von der Progammlogik nichts dazu sagen kann. Die Unterschiede zwischen UDP und TCP hast du gut getroffen. UDP ist das Basis Protokoll, schnell und ohne Fehlerbehandlung. TCP/IP halt entsprechend langsamer. Wenn es dir auf Geschwindigkeit ankommt, ist UDP das Protokoll der Wahl.

  • Wenn man aber wieder eine Arte Flußkontrolle in UDP einprogrammieren möchte, dann kann man auch gleich TCP verwenden.

    Wenn ich mich nicht irre, dann gibt es bei TCP eine option, dass das gleich rausgesendet wird.

    Ist nur eine Vermutung von mir, aber UDP wird eher für so Kontrol-Sachen benützt (kleine kurze Nachrichten). Wenn man viel Daten übertragen möchte, dann sollte das oft auch verschlüsselt passieren und da wird das auch über TCP gemacht. Vermutlich gibt es auch Gegenbeispiele zu dieser aussage.

    @Thomas - Hast Du das schon mit select probiert? - Also immer wenn man in den Buffer etwas schreiben kann, dann den Buffer voll schreiben. Aber das klingt schon eher nach einen Stream als Datagram...

  • @Mattes: Muss gestehen, dass ich NICHT daran gedacht habe, weil ich sowas noch nie verwendet habe. Sollte also nicht vorhanden sein. Aber man weiß natürlich nie. Danke für den Hinweis.

    @Wolf: Seh ich auch so! :)

    @Manoh: Wenn man das Reply automatisieren kann dann wäre das natürlich schon eine deutliche Vereinfachung. Werde mich schlau machen wie das geht.
    Eine Flusskontrolle brauch ich trotzdem. Es senden mehrere Anwendungen gleichzeitig also musste ich etwas derartiges einbauen. Wichtig ist erstmal, dass der Speed stimmt und der Programmfluss läuft. Und davon bin ich leider noch deutlich entfernt. Diese 16Mbit-Grenze macht mir echt Kopfzerbrechen...

  • Ursache gefunden!
    Oh Mann, da hab mir wiedermal selbst ins Knie geschossen!!
    Ich benütze für die Kommunikation zwischen den Anwendungen je einen Kanal fürs senden und einen für den Empfang. Am Empfangskanal unterscheide ich noch Antworten und Aktionen. Schließlich müssen Antworten synchron und Aktionen asynchron ausgeführt werden. Und bei den Antworten habe ich (aus vorigen Tests) ein usleep eingebaut für den Fall, dass eine Antwort noch nicht da ist. Eine Antwort ist aber niemals so schnell zurück, wie sie verlangt wird, also kommt zumindest ein usleep zu tragen und schon ist die Performance im Keller...
    Dank an alle für die guten Kommentare.
    Das goldende Sternchen geht an Mattes, der den richtigen Hinweis gegeben hat doch mal bei mir selbst zu suchen.
    Gruß
    Thomas

  • zu bedenken: weder UDP noch TCP garantieren eine bestimmte Geschwindigkeit. Das hängt vor allem vom Netz dazwischen ab. Wobei "Netz" auch innerhalb des Kernels liegen kann (2 lokale Anwendungen).
    Einschätzen kann man das mit "ping" (das verwendet den ICMP Echo - eine Art primitives UDP mit vorgefertigten Messages). Ein "ping localhost" bringt Erstaunliches zutage.