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
- 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
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
> Gibt es ein Programm das die effektive Verzögerung und verlorene Pakete> erfasst?
Network Instruments Observer.
Neuere Wiresharkversionen koennen das teilweise wohl auch.
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.
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.
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
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.
Eine eigene Frage?
Dieser Thread ist über 6 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
Log_33k9sec.png
(14 KB)
