Eu costumava pingfazer 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 cairá. 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
(usar -fa opção real produziu resultados semelhantes aos -i 0.00).
Por que o Flood pingdá 4us RTT enquanto o não Flood dá 8us? Se eu pular a -qbandeira fica 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 pode ser que ele possa processá-los todos ao mesmo tempo.
Uma pergunta de acompanhamento pode ser se os RTTs de ping são relevantes para o host local, pode ser que o TCP/IP não esteja sendo usado ao fazer uma solicitação HTTP do host local.
Para registro: estou executando Linux (#1 SMP Debian 3.2.68-1+deb7u2).
Responder1
Não tenho ideia de que tipo de CPU você está usando, para mim -i 0.01rende 45µs RTT, contra 8µs com -f. Essa diferença é (para minha CPU SandyBridge) aproximadamente consistente com o tempo necessário para despertar do estado de economia de energia C6:
http://ena-hpc.org/2014/pdf/paper_06.pdf
E sim, imprimir no console pode ser bastante caro, dependendo do emulador de terminal (ou ssh, etc.).