UDP Packet Test

[Alexandra (Gast)]

Hallo ihr Lieben!

Habe mal kurz ein Programm geschrieben, dass jede Sekunde ein Datenpaket 
mit dem Timestamp (auf 1000stel Sekunde) über WLAN an einen anderen 
Rechner schickt, und dort statistisch gespeichert wird. Die Auswertung 
seht Ihr im Anhang.
Am Anfang habe ich die die Uhrzeiten synchronisiert, mit naja, mehr oder 
weniger Erfolg. Die effektive Verzögerung sieht man natürlich nicht, nur 
das Driften über die 33900sec. Auch verlorene Pakete kann man so nicht 
erkennen. Interessant sind die regelmäßigen Ausreißer von ca. 200ms und 
dann und wann ein paar noch Gröbere...
Gibt es ein Programm das die effektive Verzögerung und verlorene Pakete 
erfasst?

Bussi eure Alexandra

[mr. mo (Gast)]

- Dem Graph sollte man eine Achsenbeschriftung spendieren.

- Was driftet da?

- Wie sieht das Programm zum Testen aus? Ich habe erlebt, dass selbst 1 
ms Zeitstempel Probleme bringen können. Da würde ich zunächst schauen.

- Wireshark

[(prx) A. K. (prx)]

Alexandra schrieb:
> Gibt es ein Programm das die effektive Verzögerung und verlorene Pakete
> erfasst?

Wenn die Verzögerung mitsamt Antwort gerechnet sein darf: ping
103 packets transmitted, 103 received, 0% packet loss, time 102154ms
rtt min/avg/max/mdev = 2.496/4.857/25.795/2.616 ms

Hat man nicht so viel Zeit: ping -f (Linux, root)
1831 packets transmitted, 1830 received, 0% packet loss, time 5728ms
rtt min/avg/max/mdev = 1.920/2.924/8.879/0.687 ms, ipg/ewma 3.130/3.275 
ms

[Larry (Gast)]

> Gibt es ein Programm das die effektive Verzögerung und verlorene Pakete
> erfasst?

Network Instruments Observer.

Neuere Wiresharkversionen koennen das teilweise wohl auch.

[Irgend W. (Firma: egal) (irgendwer)]

Alexandra schrieb:
> Auch verlorene Pakete kann man so nicht
> erkennen.

Wieso nicht? Wenn man 60 Pakete pro Minute abschickt weiß man doch auch 
das 60 ankommen müssen. Und wenn du 33900sek. lang gemessen hast müssen 
auch mindestens 33899 Pakete angekommen sein (eins könnte ungünstigsten 
Falls noch unterwegs sein). Und normalerweise schickt man sich bei sowas 
einfach eine Referenz Zähler im Payload mit, damit sieht man sofort wenn 
was fehlt.
Interessant wäre es ggf. für dich auch mal den Payload auszuwerten ob 
der überhaupt fehlerfrei übertragen wurde.
Insgesamt würde ich erstmal damit anfangen zu schauen wie genau dein 
Programm überhaupt die Pakete verschickt in dem du mal auf dem 
Ursprungsrechner das Ganze eine Wireshark beobachtest. Danach dann das 
Ganze auf dem Zielrechner. Zwischen Empfang des Paketes durch den NIC, 
der Verarbeitung durch das OS und bis zur Weitergabe an die Applikation 
kann auch nochmal einiges an (stark schwankender) Zeit vergehen.

[Guest (Gast)]

Irgend W. schrieb:
> Interessant wäre es ggf. für dich auch mal den Payload auszuwerten ob
> der überhaupt fehlerfrei übertragen wurde.

Das ergibt keinen Sinn. Wenn ein Paket verstümmelt wird, stimmt die 
Checksumme nicht mehr und das Paket wird verworfen. Ergo wäre bei allen 
empfangenen Paketen die Payload korrekt.

Zum messen der Strecke wäre Qosium Scope von Kaitotek zu empfehlen.

[Alexandra (Gast)]

Huhu!

Ich habe schnell mit PureBasic programmiert, Source im Anhang. 
"msDate.pbi" ist nur eine Bibliothek für die ms. Schnell zeichnete sich 
ab, dass der Aufwand für eine Auswertung der Anzahl der Pakete, sowie 
der effektiven Verzögerung immens würde, deshalb die Frage nacheiner 
fertigen Lösung.
Ja das Diagramm ist in der X-Achse die Zeit, Total 33600 Sekunden, also 
9h 20min. Y-Achse relative Verzögerungszeit in ms.

Eure Alexandra

[Εrnst B. (ernst)]

      Empfangen.s = Str(Val(msFormatDate("%ms", msDate()))+
                            Val(msFormatDate("%ss", msDate()))*1000+
                            Val(msFormatDate("%ii", msDate()))*1000*60+
                            Val(msFormatDate("%hh", msDate()))*1000*60*60+
                            Val(msFormatDate("%dd", msDate()))*1000*60*60*24)+Chr(10)

Mal überlegt, was msDate() zurückgibt, wenn man es mehrfach 
hintereinander aufruft, so wie du? Was passiert mit deiner Rechnung, 
wenn genau zwischen zwei Aufrufen der milisekunden-Zähler überläuft?

Konkret:
msFormatDate("%ms", msDate()) ---> 999 (+0Sekunden)
Zeile drauf
msFormatDate("%ss", msDate()) ---> 1 Sekunde (+0 ms)

Und schon hast du einen Eine-Sekunde-Ausreißer im Graph, der garnicht 
echt stattgefunden hat.