Latenzmessung in Ethernet Netzwerken

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.

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.

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.

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?