Verzögert gesendete UDP Packete

N

nathan2225

Jungspund
Ich habe ein merkwürdiges Verhalten beim Senden von UDP Packeten.

Ich schicke in schneller Folge eine Reihe von UDP Packeten an unterschiedliche Ziele und zwar über non-blockings sockets, die ich jeweils
neu öffne, mit connect() mit Ziel verbinde, mit write() hinausschreibe und gleich den Sockel wieder schließe.

Jetzt passiert es sporadisch, dass mache dieses Packete erst ziemlich exakt eine Sekunde später wie es scheint versendet werden.
Dazwischen sehe ich Antwort-Packete hereinkommen und auch meine App sendet weitere Packete (unicast UDP und broadcast UDP).

Wie kann das möglich sein ? Hat da wer eine Idee ?
Ich hatte schon meinen Switch in Verdacht, dass der rate control macht, aber die ist abgeschaltet ...


System:Linux Kernel 2.6.27.28, slackware 11.0, VIA Epia LT board (VIA rhine LANchip)
 
Sender und Empfänger direkt verbinden, dann testen, um switch auszuschliessen.
Wenn hier auch Verzögerung, dann muß man weiterschauen...
 
Sender und Empfänger sind quasi direkt verbunden, der Empfänger verfügt über einen integrierten 5port Switch ...
Dort leite ich durch port sniffing den traffic auch auf einen PC um und sehe daher allen Netzverkehr von und zu dem Port (linux Gerät), wo das Problem auftritt.
 
wird es wirklich verzoegert gesendet? du schreibt "scheint" ...
du koenntest lokal mit tcpdump bzw. wireshark mal sniffen, wann die Pakete wirklich raus gehen bzw. auf der Gegenseite auch sniffen wann die ankommen
http://www.wireshark.org/
 
Yep, das war mein nächster Ansatz, mich mal mit tcpdump reinzuhängen ...
Somit sollte dann feststehen, ob wirklich das Senden verzögert.
Leider ist bei etwa 10 Versuchen das Problem nicht aufgetreten, wobei es sonst etwa in 30% der Versuche auftritt.
Ev. verändert tcpdump das Timing etwas oder das Verhalten ändert sich durch den Promiscuous Mode (tcpdump default)

Was noch von Bedeutung sein könnte, es kommen auch einige IGMP Packete an, weil diese UDP Steuerbefehle eine Audio-Multicast Sendung vorbereiten.

Habe nur gehofft, es hat wer einen Idee, wie es zu diesem Verhalten kommen kann, dass einfach ein Packet 1s irgendwie im Stack/OS aufgehalten werden könnte, weil die 1s ist signifikant.

Ob das ev. damit zusammenhängen kann, dass ich über getrennte Sockets versende, die ich gleich wieder schließe.


Hmm anderer Gedanke: Ev kommt es zu der Verzögerung durch einen fehlenden ARP Eintrag und die Antwort dauert aus irgendwelchen gründen 1 s ... Das werd ich mal als nächstes checken .. (arp cache löschen und tcpdump udp or arp)
 
Zuletzt bearbeitet:
Zurück
Oben