Eu usei ping para fazer uma estimativa do limite inferior para os tempos de solicitação HTTP como parte de um estudo de viabilidade.
Para tornar o teste mais rápido, diminuí o intervalo do ping (para obter pings suficientes para obter uma média razoável) e observei que, se o intervalo ficar curto, o RTT contra o host local cairia. Por exemplo:
>sudo ping -i 0.01 -c500 -q localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
--- localhost ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 5986ms
rtt min/avg/max/mdev = 0.006/0.007/0.055/0.004 ms
>sudo ping -i 0.00 -c500 -q localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
--- localhost ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 0.003/0.004/0.016/0.000 ms, ipg/ewma 0.018/0.004 ms
(usando a opção -f real gerou resultados semelhantes aos de -i 0.00 ).
Por que a inundação ping gera 4t RTT enquanto a não inundação dá 8us? Se eu pular o sinalizador -q , ele ficará ainda pior, pois a não inundação chegará a 34us. Por que essa diferença para imprimir uma linha para cada ping individual?
Meu palpite é que os pacotes ICMP são colocados em uma fila e há uma latência antes que o kernel processe a fila e, se houver mais pacotes ICMP, ele poderá processar todos da mesma maneira.
Uma pergunta de acompanhamento pode ser se os RTTs de ping forem relevantes para o host local, pode ser que o TCP / IP não esteja sendo usado ao fazer uma solicitação HTTP de localhost.
Para o registro: Estou rodando Linux (# 1 SMP Debian 3.2.68-1 + deb7u2).
Eu não tenho idéia do tipo de CPU que você está usando, para mim -i 0.01 rende 45µs rtt, contra 8µs com -f . Essa diferença é (para minha CPU SandyBridge) aproximadamente consistente com o tempo necessário para uma ativação do estado de economia de energia C6:
E sim, imprimir no console pode ser muito caro, dependendo do seu emulador de terminal (ou ssh, etc.).
Tags performance networking ping