作为可行性研究的一部分,我曾经ping
对 HTTP 请求时间的下限进行了估计。
为了使测试更快,我降低了 ping 的间隔(以获得足够的 ping 以获得合理的平均值),并注意到如果间隔变短,针对本地主机的 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
时 RTT 为 4us,非洪水时 RTT 为 8us?如果我跳过该-q
标志,情况会变得更糟,因为非洪水将长达 34us。为什么为每个单独的 ping 打印一行会有这种差异?
我的猜测是,ICMP 数据包被放入队列中,并且在内核处理队列之前存在延迟,如果有更多 ICMP 数据包,则可能可以同时处理它们。
后续问题可能是 ping RTT 是否与本地主机相关,可能是在执行本地主机 HTTP 请求时未使用 TCP/IP。
郑重声明:我正在运行 Linux (#1 SMP Debian 3.2.68-1+deb7u2)。
答案1
我不知道你使用的是什么类型的 CPU,对我来说-i 0.01
产生 45μs rtt,而-f
.这个差异(对于我的 SandyBridge CPU)与从 C6 省电状态唤醒所需的时间大致一致:
http://ena-hpc.org/2014/pdf/paper_06.pdf
是的,打印到控制台可能会非常昂贵,具体取决于您的终端模拟器(或 ssh 等)。