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
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.
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.
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.
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.
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.
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
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.
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
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?
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. |
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.