Раньше я ping
оценивал нижнюю границу времени HTTP-запросов в рамках технико-экономического обоснования.
Чтобы ускорить тест, я уменьшил интервал пинга (чтобы получить достаточно пингов для получения разумного среднего значения) и заметил, что если интервал становится коротким, RTT для локального хоста падает. Например:
>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
(использование фактического -f
варианта дало результаты, аналогичные -i 0.00
).
Почему флуд ping
дает 4us RTT, а нефлуд дает 8us? Если я пропускаю флаг, -q
становится еще хуже, так как нефлуд доходит до 34us. Почему эта разница для печати строки для каждого отдельного пинга?
Я предполагаю, что пакеты ICMP помещаются в очередь, и возникает задержка, прежде чем ядро обработает очередь, и если пакетов ICMP больше, оно может обработать их все за один раз.
Дополнительный вопрос может заключаться в том, что если ping RTT актуальны для локального хоста, то, возможно, TCP/IP не используется при выполнении HTTP-запроса локального хоста.
Для справки: я использую Linux (#1 SMP Debian 3.2.68-1+deb7u2).
решение1
Я понятия не имею, какой тип процессора вы используете, для меня -i 0.01
это дает 45 мкс rtt, против 8 мкс с -f
. Эта разница (для моего процессора SandyBridge) примерно соответствует времени, необходимому для пробуждения из состояния энергосбережения C6:
http://ena-hpc.org/2014/pdf/paper_06.pdf
И да, печать на консоль может быть довольно затратной, в зависимости от вашего эмулятора терминала (или ssh и т. д.).