Назад | Перейти на главную страницу

асимметричное время ping, но постоянное время xfer файла?

Когда я пингую систему a от системы b; Я получаю в среднем 1,494 мс. Когда я пингую систему b из системы a; Я получаю в среднем 0,896 мс.

Я запускал тестовый пинг каждые 10 секунд в течение 1,5 часов. Я запустил это на обеих машинах. Затем я повторил тест несколько раз в течение 6 дней в разное время и в течение разного времени. Во всех случаях пинги от b-> a out выполняли пинги от a-> b от 20% до 50%.

Затем я попытался передать файлы из a-> b и b-> a. Они различались менее чем на 5%.

Это идентичные серверы Linux RedHat. То же оборудование, то же программное обеспечение.

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

Что, черт возьми, могло быть причиной этого, и как мне проверить, так ли это?

Спасибо

Стоит сделать traceroute от A-> B и B-> A. Если вы не знаете иначе, вполне возможно, что трафик в прямом направлении идет по другому пути, чем в обратном.

Можно было бы ожидать, что это будет разрешено, учитывая, что ICMP измеряет время прохождения туда и обратно, но я видел подобное асимметричное время ping в сетях, где трафик в заданном направлении смещается по определенным каналам.

Я предполагаю что a и b находятся в отдельных дата-центрах? Возможно, с разными операторами восходящего потока?

Пинг реализован по ICMP, который является совершенно отдельным от TCP типом трафика, и, поскольку такие операторы бесплатны (и обычно это делают), снижают приоритетность трафика ping. Возможно, вы заметили этот эффект при тестировании.

Вы можете подтвердить это с помощью таких инструментов, как mtr, или tcpping, которые используют альтернативные методы для имитации пинга.

изменить: вы проверили настройки дуплекса на каждом интерфейсе между a и b? Если что-то не удалось автоматически определить и установить по умолчанию полудуплексный режим, это может объяснить наблюдаемые вами результаты (хотя менее вероятно, что вы получите приемлемую скорость передачи при несовпадении дуплексного режима).