Как объяснить низкий RTT между чрезвычайно длинными (10 с) интервалами пинга?

Question

Я использую утилиту ping для устранения проблем, связанных с медленным подключением к Интернету в моей домашней сети, но я нахожу результаты необычными и трудными для интерпретации.

У меня есть беспроводной маршрутизатор Linksys, и я попробовал следующие одновременные тесты: проверить связь с маршрутизатором с моего компьютера, проверить связь с google.com с маршрутизатора и проверить связь google.com с моего компьютера через маршрутизатор. Пинг-роутер с компьютера и пинг Google с роутера работают как положено, с минимальной потерей пакетов и малым временем приема-передачи (min /avg /max = 1.601 /3.465 /9.926 и 20/20/70 соответственно),

Однако пинг Google с моего компьютера через роутер сообщает о чем-то, что мне кажется очень странным. Он сообщает о низком RTT и минимальной потере пакетов, но интервал каждого запроса проверки связи, который должен быть равен 1 с по умолчанию, больше похож на 10 с. Это выглядит так, как будто задержка составляет 10 секунд между каждым выводом команды ping. Но в результате RTT низкий, например:

64 байта из 74.125.226.115: icmp_seq = 31 ttl = 52 время = 29,2 мс

Когда я запускаю это параллельно с другими тестами, другие тесты будут отправлять около 100 запросов в то время, когда этот тест отправит 10. Это, кажется, противоречит низкому RTT, о котором сообщают, таким образом, я не уверен, как понять это.

Буду признателен за любую информацию, которую может предложить каждый.

Answer 1

Кажется, что ping выполняет разрешение имен перед каждой отправкой ICMP-запроса.

Возможно, это реализовано таким образом, что долго выполняющийся эхо-запрос будет продолжать эхо-запрос правильного хоста, даже если сопоставление IP-адреса хоста <-> изменяется во время выполнения.

Если существует задержка в разрешении имен (например, из-за того, что RR имеет очень низкий TTL и ваш кеширующий DNS-сервер не применяет минимальный TTL), то вы, скорее всего, увидите большие задержки между каждым ICMP-запросом, но отдельные ответы, имеющие низкий TTL.

Короче говоря, как предложено в другом месте, попробуйте ping -n.

Answer 2

Запустите ping с параметром -n , чтобы он не выполнял обратное разрешение имен. Вероятно, это программное обеспечение dns вашего маршрутизатора, и ping ожидает результата поиска dns, а не ответа icmp.

Если -n помогает, у вас есть два варианта:

• починить роутер
• переключиться на какой-либо общедоступный DNS-провайдер на вашем компьютере (например, Google Public DNS)

Answer 3

У меня также была проблема с «вялыми» результатами пинга после установки dd-wrt в качестве маршрутизатора gw. Я также заметил «вялый» пинг из коробок Linux, но никаких проблем из окон Windows. Я попытался запустить с -n, и это улучшило пинг!

Вопрос в том, что является первопричиной, как это исправить, чтобы поиск шел быстрее, чем раньше?

Answer 4

Попытка запустить ping с опцией -n чтобы он не пытался искать имена. Если он продолжает пытаться найти DNS-имя хоста компьютера, с которого вы отправляете эхо-запрос (или какого-либо маршрутизатора, который отправляет сообщения ICMP Unreachable), это может препятствовать эхо-тестированию, достаточному для того, чтобы он не получал более одного пакета каждые несколько секунд.

Answer 5

Предложение QoS является хорошим, но я ожидаю, что компьютер сообщит о других девяти пингах как потерянных, если QoS отбросит их, или с увеличением значений RTT, если маршрутизатор удерживал их для QoS и отправлял их партиями.

Я бы посоветовал проверить, может ли ping иметь псевдоним ping -i 10 , что заставляет его отправлять только один пакет в 10 секунд. Кроме того, вы можете попробовать выполнить команду ping -i 1 <host> чтобы заставить ее отправлять пинги с интервалом в одну секунду.

Обратите внимание, что предполагается, что вы имеете в виду, что один результат пинга (с низким RTT) печатается каждые десять секунд. Если вы получаете десять результатов каждые десять секунд, но все они приходят сразу, а не равномерно распределены один раз в секунду, то это звучит так, как будто на вашем дисплее происходит какая-то буферизация вывода.

Answer 6

Есть ли какая-либо функция QoS на вашем маршрутизаторе (особенно если она указана в Tomato или DD-WRT), ограничивающая или преуменьшающая приоритетность трафика ICMP? Это может быть маршрутизатор ограничивает скорость пингов. Таким образом, возможно, маршрутизатор разрешает узлам ЛВС выдавать только 1 пинг в 10 секунд, но когда этот пинг разрешен, он работает нормально, что может объяснять низкий RTT, но большие задержки.

Answer 7

Я знаю, что это старый вопрос, но мы столкнулись с проблемой длительных пауз между пингами на наших старых машинах, и проблема заключалась в ошибке в демоне Avahi, когда у домена нет записи PTR. Как только мы отключили этот демон (остановка службы sudo avahi-daemon), паузы исчезли.

Вот соответствующая статья: http://www.unchartedbackwaters.co.uk/pyblosxom/debian_ubuntu_dns_resolution_delays

Отслеживание ошибок Ubuntu: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940

Отслеживание ошибок Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414569

Answer 8

Вы пинговали google.com или IP-адрес? Вы не можете подключиться к одному и тому же серверу, отправив ping на google.com, на котором указаны тысячи серверов, и в зависимости от того, где вы живете, вы можете быть перенаправлены на один или несколько из них из-за нагрузки на сервер в любой момент времени.