[Dump] userspace latency

[Markus Kittenberger]

da ja seit akku nach ping-artigen metriken lechszt,.. (-;

gerne von verschiednen seiten: das geht nicht verkündet wurde,.

mit derartigen begründungen:

ping macht zuviel nichtnutzbaren traffic
und leider solche messungen angeblich nur mit ping und dessen
im-kernel-space reply überhaupt gut möglich wären,..

ersters stimmt natürlich, und auch die zwingend symmetrische antwortgrösse
vom icmp echo/reply ist nich das allerfeinste,..

aber 2.tens hab ich seit jeher in zweifel gezogen,..

und da man c kenntnisse inzwischen ausreichend sind um über udp sockets
messages zu schicken/empfangen,.. (-;

obowhl ich im endeffekt dann eh ein fastfertiges sample im internet dafür
gfunden hab.. *g
(source und whiterussian binaries siehe
http://texas.funkfeuer.at/~markus/udp_latency)

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,..

somit ists egal ob das relpy erst sekunden später weggeschickt wird, (wenn
sowieso z.b. ein anderes hello paket retour ginge)

man muss nur das zeitdelta seit zum empfangstimestamp zrückschicken und gut
ists

jedenfalls hab ich auf normalen servern gleiche latenzzeiten wie mit pinf
gemessen, und auf linksys und buffalo um .5 msec niedrigere,..

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,..

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",.

nunja im grunde nix weltbewegendes, nona macht der kernel brauchbare
timestamps, tcpdump zeigt sie ja auch an,..

aber ein schöner proof, denn meine olsr-erweiterungen brauchen gut-messbare
latenzen,..

lg Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/dump/attachments/20081226/08dc8672/attachment.html>