UDP Packet Test

Alexandra Gast #6425941
Lesenswert?
• ▲
▼ 
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
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
mr. mo Gast #6425943
Lesenswert?
• ▲
▼ 
- 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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #6425944
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Irgend W. (Firma: egal) #6426259
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Guest Gast #6426270
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Alexandra Gast #6426399
Lesenswert?
• ▲
▼ 
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
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Εrnst B. #6426438
Lesenswert?
• ▲
▼ 
1
      Empfangen.s = Str(Val(msFormatDate("%ms", msDate()))+

2
                            Val(msFormatDate("%ss", msDate()))*1000+

3
                            Val(msFormatDate("%ii", msDate()))*1000*60+

4
                            Val(msFormatDate("%hh", msDate()))*1000*60*60+

5
                            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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren