La raison pour laquelle j’ai procédé comme ça, c’est qu’il est impossible de mesurer directement le temps de traitement d’un seul paquet.
Avec un flood à quasiment 8 Mo/s (soit environ 130000 pings par seconde à raison de 64 octets par ping*), la charge CPU n’est qu’à 5 % dans le pire des cas. Si le réseau arrivait à suivre (bande passante infinie), en saturant le CPU il pourrait traiter grosso modo 20 fois plus de paquets (2600000 par seconde) c’est à dire 0.000385 millisecondes (385 nanosecondes) pour traiter un paquet.
(*) j’ai comme un doute quand même, je me demande si les trames Ethernet ne sont pas de taille fixe (1500 octets) quel que soit le contenu.
Qu’à cela ne tienne, le calcul est identique : 8 Mo/s ça nous fait 5590 pings par seconde, soit une capacité de traitement CPU (x 20) de 111800 paquets par seconde, c’est à dire 0.009 millisecondes (9 microsecondes) par paquet. Étant donné que les 385 nanosecondes me paraissent quand même vachement faibles, je pense que c’est plutôt les 9 microsecondes qui sont correctes. Mais bon, même comme ça on est quand même à des valeurs 100 fois plus petites que la milliseconde !
Ça, c’est sur un “petit” CPU à 1.66 GHz, avec plus de 128000 règles, dans le cas le plus lent (iptables, machine de test tout à la fin de la liste noire).
Dans ces conditions, comment veux-tu mesurer de manière fiable le temps de traitement d’un seul paquet alors que ta précision de mesure est au mieux d’une milliseconde, et que le simple fait de lancer un programme comme netcat implique déjà des variations de plusieurs millisecondes ? 
Et c’est pas mes quelques arrondis qui vont changer l’ordre de grandeur de manière significative…
Je ne comprends pas ton histoire de pondération par la durée. La charge réseau était stable, la charge CPU était stable, la stabilité de la mesure a été vérifiée à chaque fois sur une grosse minute, je ne vois pas ce qu’il y a à pondérer. Tu peux détailler ?
).
