Paketverluste auf Empfängerseite UDP nur bei WLAN

PhilippM

Servus,

mich plagt hier ein echtes Prob.
Ich habe einen UDP-Unicast zwischen zwei Applikationen am laufen.
Der funktioniert klasse, solange alles verdrahtet ist. Benutze ich jedoch WLAN, habe ich Paketverluste jenseits der 50%.
Ich habe mehrere WLAN-Router ausprobiert (T-Offline Slowport, D-Link, Apple Airport), mehrere WLAN-Empfänger (intel broadcom, apple, Fritz Stick) und es ist immer dasselbe.
Per Wireshark bin ich nun soweit, dass die Pakete definitiv verschickt werden.
Aber die Empfängerseite droppt sie massenhaft.

Problem ist, dass die Pakete in "Bursts" verschickt werden. Aufgrund der Aufgabe meines Clienten gehen recht kleine Pakete (16 Bytes Nutzlast) viermal pro Sekunde auf die Leitung, und zwar pro Zyklus zwischen 20 und 80 Stück davon. Außerdem gibt es Intervalle, in denen große Synchronisierungen stattfinden, da kommen alle 15sec auch mal 120 Pakete a 16Byte Nutzlast. Und gerade die gehen massenhaft verloren.
Da ich leider auf der Senderseite so gut wie nichts am Verhalten ändern kann, muss ich den Empfänger dazu bringen, auch mal solche "Bursts" verarbeiten zu können.

Das Problem tritt Betriebssystemübergreifend (Linux, Mac) auf und wie gesagt NUR bei WLAN. Und bevor jetzt die Unkenrufe kommen, UDP-Anwendungen MUESSEN Paketverlust vertragen: Ja, das verträgt meine Anwendung grundsätzlich auch, aber nicht deutlich größer 50% der Gesamtmasse an Paketen.

Der Code auf der Senderseite ist ein ganz simples sendto(),
auf Empfängerseite ist es ein QUDPSocket, der dem Beispielcode von Trolltech entspricht

while(m_read_socketdevice->hasPendingDatagrams())
    {
        QByteArray buffer;
        buffer.resize(m_read_socketdevice->pendingDatagramSize());
        long read_bytes = m_read_socketdevice->readDatagram(&buffer, buffer.size());
    }

Irgendwelche Vorschläge von Netzwerkgurus?

Danke im Voraus,
Phil

Badestrand

Ich denke nicht, dass du auf dieser Ebene Einfluss auf den Paketverlust nehmen kannst.

PhilippM

Ich bin nicht mit QUDPSocket verheiratet. Also eine recvfrom-Lösung könnte man da auch machen. Ich müsste nur mal wissen, wie ich den Empfänger dazu bringe, die Pakete annzunehmen, auch wenn er sie nicht unmittelbar weiterverarbeiten kann. Und warum eigentlich nur bei WLAN????

Badestrand

Und warum eigentlich nur bei WLAN????
Nunja, wegen schlechtem Empfang zum Beispiel?

So wie du das Problem beschreibst (plattformübergreifend, Router- und Empfängerunabhängig), wirst du im Application-Layer wenig ausrichten können. Anlaufstelle wäre eher die Treiberebene, wobei du auch da nicht viel ausrichten können wirst. Die UDP-Pakete werden sicherlich verworfen, weil sie kaputt sind, da hast du keine Handhabe..
Wenn du die Senderseite ändern kannst, könntest du das Protokoll etwas verlässlicher machen, z.B. einige Pakete nachschicken oder so. Oder probieren, größere und dafür weniger Pakete zu schicken.

PhilippM

Sogar wenn ich zwei Notebooks in zehn Zentimeter Abstand mit einer ad-hoc WLAN-Verbindung aufstelle, verliere ich eines von zwei Paketen.

Weniger größere Pakete sind eine Idee, die ich verfolgen werde.

Aber nochmal: Wieso Treiberebene? Dann müssten ja ALLE Treiber von Apple, Fritz, Intel fehlerhaft sein?

Und wie können 50% der Pakete unterwegs kaputt gehen, bei 100% Empfangsstärke?

Badestrand

PhilippM schrieb:

Aber nochmal: Wieso Treiberebene? Dann müssten ja ALLE Treiber von Apple, Fritz, Intel fehlerhaft sein?

Nein, nicht fehlerhaft, aber das ist die Stelle, wo du Zugriff auf's Netzwerk hast.

PhillipM schrieb:

Und wie können 50% der Pakete unterwegs kaputt gehen, bei 100% Empfangsstärke?

Keine Ahnung. Kannst ja mal ein Test-Tool drüberlaufen lassen, z.B. das (laut Beschreibung soll das Tool verlorene Pakete anzeigen können), gibt's ne Trial-Version von.

ich bezweifle sehr, dass irgend eine software auf einer oder beiden seiten des transfers ein korrektes udp paket verwerfen würde. die pakete werden nur verworfen, wenn zu viele ankommen. 120 pakete pro sekunde kann nicht zu viel sein. das sollte nicht mal annährend ein problem sein. wäre es das, würde das problem auch bei der kabelgebundenen lösung existieren.
ich vermute, dass du einfach pakete im wlan verlierst. ein wlan ist nun mal nicht für solche sachen geeignet, da ja auch andere leute mehr oder weniger auf der gleichen leitung herumsenden. installier dir mal kismet und suche nach anderen wlans. dann schaust du, welche der wlan kanäle wenig verwendet wird und stellst den bei deinem wlan ein. das könnte dir helfen, ich halte es aber für eher aussichtslos, dass du 100% der abgeschickten pakete je empfangen wirst.

besserwisser schrieb:

ich vermute, dass du einfach pakete im wlan verlierst. ein wlan ist nun mal nicht für solche sachen geeignet, da ja auch andere leute mehr oder weniger auf der gleichen leitung herumsenden.

doch, wlan ist dafür geeignet. gerade weil der verwendete frequenzbereich ziemlich schmutzig sein kann, verwendet wlan ausgeklügelte mechanismen wie retransmissions, fehlerkorrigierende codes, selbständige adaption der übertragungsraten, usw.
PhillipM: du hast schon router getauscht, hast du auch mal die wlan-hardware der clients getauscht bzw. deren treiber? ich vermute mal, dass es eher ein software-problem ist. jedenfalls sind 50% paketverlust alles andere als normal.

PhilippM

+fricky schrieb:

PhillipM: du hast schon router getauscht, hast du auch mal die wlan-hardware der clients getauscht bzw. deren treiber? ich vermute mal, dass es eher ein software-problem ist. jedenfalls sind 50% paketverlust alles andere als normal.

Ich schreib doch: Es ist dasselbe, ob ich mit einem MacBook Pro WLAN empfange, mit einem Intel Broadcom Adapter in einem Dell Notebook, oder mit einem Fritz! WLAN USB-Stick an einem Desktoprechner. Überall dasselbe.

besserwisser schrieb:

die pakete werden nur verworfen, wenn zu viele ankommen. 120 pakete pro sekunde kann nicht zu viel sein. das sollte nicht mal annährend ein problem sein.

Das Problem ist wahrscheinlich eher, dass die 120Pakete pro Sekunde nicht als 1 Paket alle 1/120stel Sekunde kommen, sondern in einem Burst, da eine Schleife durchgelaufen wird, die einfach 120mal sendto aufruft, ohne sleep dazwischen.
Wobei 120 allerdings der Maximalwert ist. Normalerweise sind es vielleicht 80.

PhilippM schrieb:

+fricky schrieb:

PhillipM: du hast schon router getauscht, hast du auch mal die wlan-hardware der clients getauscht bzw. deren treiber? ich vermute mal, dass es eher ein software-problem ist. jedenfalls sind 50% paketverlust alles andere als normal.

Ich schreib doch: Es ist dasselbe, ob ich mit einem MacBook Pro WLAN empfange, mit einem Intel Broadcom Adapter in einem Dell Notebook, oder mit einem Fritz! WLAN USB-Stick an einem Desktoprechner. Überall dasselbe.

ok, da aber das verhalten durchaus ungewöhnlich ist (50% verlust sind einfach nicht normal): was ist gleich geblieben?
- die umgebung?
- software die du zum testen benutzt hast?
- das OS?
wenn du diese komponenten auch noch mal wechseln würdest, könntest den übeltäter finden.

kann es sein, dass das wlan qos die pakete verwirft? random early detection fällt mir da mal ein. vielleicht ist dem qos eine so hohe rate an udp paketen zu viel.

pakete werden nur aus zwei gründen verworfen:
- zur staukontrolle
- pakete sind kaputt (inklusive ganz verlorener pakete)

im wlan ist die wahrscheinlichkeit für punkt zwei eindeutig höher als in einem kabelgebundenen netzwerk.

PhilippM

Hallo,

ich habe jetzt nochmal ein bißchen probiert und "gewiresharkt".
Das Ergebnis: Die kritische Situation ist Empfänger am WLAN.
Wenn der Sender am WLAN hängt, und der Empfänger am Kabel, gehen keine Pakete verloren, ebenso wie wenn beide am Kabel hängen.
Wenn der Empfänger auf WLAN ist und der Sender auf Kabel, habe ich Verluste. (Dito beide auf WLAN).

Unter Windows habe ich doppelt so viele Verluste wie auf Linux, obwohl beidesmal der gleiche Adapter (Intel 3945ABG).

Aber das aller merkwürdiste ist die Wireshark-Ausgabe. Wenn ich sowohl auf Sender als auch Empfänger Wireshark mitlaufen lassen, werden auf dem Sender 100% der Pakete als "Checksum Bad" markiert, aber auf dem Empfänger werden sie merkwürdigerweise im Wireshark alle als okay angezeigt. Trotzdem verliert meine Applikation immernoch einige!

Wireshark Screenshot Sender:
http://vas.philippmuenzel.de/ws.png

Das halte ich aber für nicht signifikant, da wie gesagt der Sender-WS 100% aller Pakete für kaputt hält.

Hilft das irgendwie weiter?

PhilippM schrieb:

Unter Windows habe ich doppelt so viele Verluste wie auf Linux, obwohl beidesmal der gleiche Adapter (Intel 3945ABG).

wenn du unter linux 50% verlierst, kommt unter windoofs gar nichts mehr an, oder was meinst du damit?

PhilippM schrieb:

Aber das aller merkwürdiste ist die Wireshark-Ausgabe. Wenn ich sowohl auf Sender als auch Empfänger Wireshark mitlaufen lassen, werden auf dem Sender 100% der Pakete als "Checksum Bad" markiert, aber auf dem Empfänger werden sie merkwürdigerweise im Wireshark alle als okay angezeigt.

das kann schon mal vorkommen. wenn die netzwerk-hardware das berechnen der prüfsummen übernimmt (google mal nach 'checksum offloading'), dann bekommt sie wireshark auf der sendeseite nicht zu sehen, aber beim empfänger schon.

schon mal 'ne WLAN ad-hoc verbindung probiert? aber ich schätze mal, da kommt das gleiche raus. hast du auch mal (in der konfiguration 'sender am draht, empfänger am WLAN') den wlan-adapter getauscht (also einen anderen als den Intel 3945ABG benutzt)?

PhilippM

Sodele, ich hab ds Problem jetzt einigermaßen in den Griff bekommen - dachte ich zumindest.

Ich hab meinen Sender so ungeschrieben, dass die Pakete gequeued werden und nichtmehr in einzelen Bursts kommen, also 20 Pakete, Pause, 50 Pakete, Pause, 10 Pakete, Pause, sondern sie möglichst gleichmäßig mit etwa 80-100 Paketen/sec "plätschern". Das scheint sich sehr gut auszuwirken und hat den Packetloss auf Empfängerseite auf Linux auf Null reduziert, und auf Windows auf nahezu Null.

Jetzt habe ich das ganze mal auf Multicast umgestellt. Und nu geht nix mehr... Jetzt kommt noch etwa jedes 100ste Paket beim Empfänger an.

Ist UDP-Multicast über WLAN vielleicht generell eine schlechte Idee?