<p>da ja seit akku nach ping-artigen metriken lechszt,.. (-;<br></p><p>gerne von verschiednen seiten: das geht nicht verkündet wurde,.</p><p>mit derartigen begründungen:<br><br>ping macht zuviel nichtnutzbaren traffic<br>und leider solche messungen angeblich nur mit ping und dessen im-kernel-space reply überhaupt gut möglich wären,..</p>
<p>ersters stimmt natürlich, und auch die zwingend symmetrische antwortgrösse vom icmp echo/reply ist nich das allerfeinste,..</p><p>aber 2.tens hab ich seit jeher in zweifel gezogen,..<br></p><p>und da man c kenntnisse inzwischen ausreichend sind um über udp sockets messages zu schicken/empfangen,.. (-;</p>
<p>obowhl ich im endeffekt dann eh ein fastfertiges sample im internet dafür gfunden hab.. *g<br>(source und whiterussian binaries siehe <a href="http://texas.funkfeuer.at/~markus/udp_latency">http://texas.funkfeuer.at/~markus/udp_latency</a>)<br>
</p><p>nunja jedenfalls kann man setsockopt(sock,SO_TIMEOUT) machen, und kriegt dann den kernel timestamp zu jeden paket, d.h. man kann ruhig nonblocking mit "riesigen" pollinterval auf pakete warten, und trotzdem die zeit messen wann es ankam,..</p>
<p>somit ists egal ob das relpy erst sekunden später weggeschickt wird, (wenn sowieso z.b. ein anderes hello paket retour ginge)</p><p>man muss nur das zeitdelta seit zum empfangstimestamp zrückschicken und gut ists</p><p>
jedenfalls hab ich auf normalen servern gleiche latenzzeiten wie mit pinf gemessen, und auf linksys und buffalo um .5 msec niedrigere,..</p><p>allerdings sind sie imho richitg, d.h. 0,5msec via lan zum nächsten anstatt 1msec ping, aber eben auch 5.5msecs über 6 hops wo ping im langzeitdurchschnitt 6 msecs hatte,..</p>
<p>da ich nebenbei auch die latenz des netzwerk stacks + schedulers damit messen konnte (zeitdifferenz zwischen kernel timestamp und empfangen mit einem blocking recvmsg(sock,) welche meistens ca. 0,5 msec betrug bin ich auch ziemlich sicher woher dieser unterschied herrührte, das ping utility selber rennt ja ganauso im userspace, nur das reply beim gegenüber wird "blitzschnell" von dessen kernel gemacht, aber beim empfangen nutzt das nix,.. und darum ist mein test der sowhl beim gegenüber als auch lokal die kerneltimestamps verwendet, eben quasi "schneller",.</p>
<p>nunja im grunde nix weltbewegendes, nona macht der kernel brauchbare timestamps, tcpdump zeigt sie ja auch an,..</p><p>aber ein schöner proof, denn meine olsr-erweiterungen brauchen gut-messbare latenzen,..</p><p>lg Markus</p>
<p><br></p>