Forum: PC Hard- und Software Latenzmessung in Ethernet Netzwerken


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von NetwokingGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich stehe gerade für ein Projekt vor einem Problem:

Ich möchte bei verschiedenen Ethernet Netzwerken und vor allem bei 
unterschiedlicher Konfiguration die Latenz von einem Punkt A zu B 
messen. Ich möchte dabei den Einfluss von Techniken wie z.B. Priorität 
in VLANs ermitteln, oder die Verwendung anderer Netzwerkkomponenten 
(z.B. Switches mit Cut-Through statt Store-Forward) beurteilen. Diese 
Beurteilung möchte ich bei unterschiedlichem Querverkehr im Netzwerk 
durchführen.

Mein Problem ist nun eine geeignete Messmethode ziemlich weit unten im 
OSI Modell zu finden.

Was ich aktuell gemacht habe:
- Ein C++ Programm mit Sockets implementiert, das eine Nachricht 
spiegelt und somit die Durchlaufzeit A->B->A ermittelt
- Latenzmessung mit ping

Allerdings sind diese Messungen sehr stark schwankend ca. ~200us und 
stark von der Auslastung und dem Sheduler des Betriebsystem abhängig.

Eine FPGA basierte Lösung erscheint mir zu aufwändig.

Gibts hier nicht eine einfachere Möglichkeit im us/ns Bereich Ethernet 
zu messen?

Grüße

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Du kannst Dir mal netperf anschauen:
http://www.netperf.org/netperf/

Das verwendet zwar auch TCP oder UDP - und damit den Network Stack 
Deines OS - macht die Messungen aber über ne längere Zeit und gibt Dir 
dann eine Statistik darüber raus.

Damit habe ich bisher die besten Erfahrungen für sowas gemacht.

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke du kannst dir die ns und us sparen, denn die Zeit wird eh 
durch den Kernel bestimmt. Ich wuerds mal bei ping belassen.
Denn irgendwelche andere Anzeige wird auch durch den Kernel gehen. Der 
Kernel bedeutet die Betriebssystem Zeitscheiben. Bei Windows Server sind 
das zB 100ms, Bei windows Desktop wahrscheinlich 20ms, allenfalls in 
einem high performance Abspeck Linux auf Hardware vielleicht 1ms. 
Weniger eher nicht.

Fuer alle anderen Anforderungen wuerd ich mit dem Oszilloskop auf dem 
Kabel nachmessen. Wobei das Oszilloskop die Packete nicht lesen kann.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
NetwokingGuy schrieb:
> Allerdings sind diese Messungen sehr stark schwankend ca. ~200us und
> stark von der Auslastung und dem Sheduler des Betriebsystem abhängig.

Schlimmer: In dem Bereich liegt die Interrupt Moderation moderner 
Netzwerkkarten, d.h. sie verzögern den Interrupt bei eingehendem Paket 
um diese Zeit. Hintergrund ist die mögliche Bündelung mit mehreren 
Paketen auf einmal um die CPU zu entlasten - Interrupts kosten Zeit.

Könnte man mit ethtool o.ä. ausmachen, aber dann ist der Server 
eventuell sehr viel weniger performant im Durchsatz.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Sapperlot W. schrieb:
> Denn irgendwelche andere Anzeige wird auch durch den Kernel gehen. Der
> Kernel bedeutet die Betriebssystem Zeitscheiben. Bei Windows Server sind
> das zB 100ms, Bei windows Desktop wahrscheinlich 20ms, allenfalls in
> einem high performance Abspeck Linux auf Hardware vielleicht 1ms.
> Weniger eher nicht.

So dämlich sind die Scheduler schon seeehr lange nicht mehr. Auf meinem 
08/15 Linux System gibts Ping Zeiten unter 0.5 sec bei GigE - und da ist 
Windoof die Gegenstelle.

von nicht"Gast" (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Windoof

Cooler Hund, hat Windoof geschrieben.

Hast du den Text gelesen? Da steht was von 200ms und Maulst dagegen, 
dasß es falsch ist, weil dein System unter 500ms kommt.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Man könnte auch ganz ohne bzw. mit einem "Spar-" OS messen.

Wie wäre es, z.B. den Ping auf einem Arduino mit Ethernetshield zu 
implementieren. Der hat dann gar keinen unübersichtlichen 
Multitask-Kernel, der mal dies oder mal jenes tut. Die deshalb 
wahrscheinlich immer gleichen internen Reaktionszeiten des nicht 
besonders schnellen Prozessors kann man heraus-kalibrieren ...

Man implementiert eine einfache Kommando-Syntax auf dem USB-Interface, 
setzt damit eine Ping-Sequenz einstellbarer Länge ab und holt sich danch 
die per Hardware-Timer erfassten Antwortzeiten darüber ab.

Arduino ist jetzt nur ein spontans Beispiel, wem der zu lahm ist, der 
kanns ja auch mit einem Teensy oder ähnlicher "bare metall"-Technik und 
einem Ethernet-Chip machen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man wirklich ins Detail gehen will, dann sind Ping und verwandte 
Methoden schon deshalb problematisch, weil beide Richtungen addiert 
werden. Richtungsabhängige Effekte sind so schwerer erfassbar.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dann sollte man auch die Paketlänge mit untersuchen, da größere 
Datenpakete öfter gestört werden als kurze. Vergleiche selbst:

ping 8.8.8.8 -l 999

Ping wird ausgeführt für 8.8.8.8 mit 999 Bytes Daten:
Antwort von 8.8.8.8: Bytes=64 (gesendet 999) Zeit=132ms TTL=46
Antwort von 8.8.8.8: Bytes=64 (gesendet 999) Zeit=132ms TTL=46
Antwort von 8.8.8.8: Bytes=64 (gesendet 999) Zeit=133ms TTL=46
Antwort von 8.8.8.8: Bytes=64 (gesendet 999) Zeit=130ms TTL=46

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 130ms, Maximum = 133ms, Mittelwert = 131ms

==============================selbes Ziel,selbe Quelle =========
ping 8.8.8.8 -l 20

Ping wird ausgeführt für 8.8.8.8 mit 20 Bytes Daten:
Antwort von 8.8.8.8: Bytes=20 Zeit=79ms TTL=46
Antwort von 8.8.8.8: Bytes=20 Zeit=77ms TTL=46
Antwort von 8.8.8.8: Bytes=20 Zeit=77ms TTL=46
Antwort von 8.8.8.8: Bytes=20 Zeit=78ms TTL=46

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Wie wäre es, z.B. den Ping auf einem Arduino mit Ethernetshield zu
> implementieren.

Und damit willst du mikrosekundengenaues Timing bei einem Gigabit 
Ethernet machen?

von rmu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
1
NAME
2
       bing - compute point to point throughput using two sizes of ICMP ECHO_REQUEST packets to pairs of remote hosts.
3
4
SYNOPSIS
5
       bing [dDnrRPvVwz] [-c count] [-e samples] [-f samplefile] [-i wait] [-p pattern] [-s small packetsize] [-S big packetsize] host1 host2 [...]
6
7
DESCRIPTION
8
       Bing  determines  bandwidth  on a point-to-point link by sending ICMP ECHO_REQUEST packets and measuring their roundtrip times for different packet sizes on each end of the
9
       link.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
NetwokingGuy schrieb:
> Möglichkeit im us/ns Bereich Ethernet

Bei ns Leitungslänge=? Außerdem wist Du wissen, daß auch schnelle CPUs 
nicht immer die selbe Taktzeit für einen Befehl brauchen wenn noch 
andere SW im Spiel ist. Wahrscheinlich ist es einfacher, Datenmenge und 
Messzeit so zu vergrößern, daß man leichter messen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.