Я пытаюсь оценить задержку по локальной сети. Для этого очевидной идеей было использовать ping . Так что вот так:
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.241 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.190 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.177 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.190 ms
Хорошо, но есть брандмауэр, так что, возможно, 1 секунда прерывает conntrack в брандмауэре, давайте попробуем уменьшить интервал ping -i 0.05:
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=0.119 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=0.106 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=0.104 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=0.109 ms
Это выглядит значительно быстрее. Итак, давайте возьмем еще меньший интервал ping -i 0.005:
64 bytes from 192.168.1.1: icmp_seq=2139 ttl=64 time=0.059 ms
64 bytes from 192.168.1.1: icmp_seq=2140 ttl=64 time=0.073 ms
64 bytes from 192.168.1.1: icmp_seq=2141 ttl=64 time=0.056 ms
64 bytes from 192.168.1.1: icmp_seq=2142 ttl=64 time=0.068 ms
В этот момент я собрал большой журнал пингов, затем вычислил среднее значение и оказалось: 0.068 ms . Когда я повторил тест на 8 000 больших кадров, ping -M do -s 8000 . оно установилось около 0,220 мс.
Таким образом, вопрос - что такое фактическая задержка? Почему уменьшение интервала уменьшает время отклика пинга?
Меня больше интересует задержка с большой пропускной способностью, чем случайная, потому что она должна маршрутизировать NFSv4, поэтому, вероятно, 0.220 реалистична, но я бы хотел, чтобы кто-то подтвердил.