Я измеряю время около 100-150 миллисекунд от отправки TCP SYN до получения SYN / ACK между двумя компьютерами Linux, подключенными к одному и тому же коммутатору Cisco. Рассматривать:
Итак, мои вопросы:
редактировать - Мы убрали переключатель из уравнения. Два компьютера теперь соединены перекрестным кабелем, и мы все еще наблюдаем проблему. Оба работают в полнодуплексном режиме, 100 Мбит / с.
Ну дерьмо. Похоже, я неправильно прочитал журналы tcpdump и wirehark. Задержка, которую я получал, составляла 100 микросекунд, а не миллисекунды!
альтернативный текст http://ironicsurrealism.blogivists.com/files/2009/10/homer-simpson-doh.gif
Обычные подозреваемые:
Несоответствие дуплекса
Если вы видите коллизии, это означает, что этот конец полудуплексный и должен быть установлен на полный. Если вы видите ошибки, проверьте другой конец на предмет коллизий. Если на обоих концах есть ошибки, возможно, у вас плохой кабель.
Какую модель коммутатора Cisco вы используете? Одна вещь, которая может произойти, заключается в том, что если коммутатор не знает, на каком порту находится ваш сервер, ему необходимо будет заполнить все порты пакетом, что может занять время (хотя не должно занимать 100 мс). Вы можете проверить это, запустив дамп TCP на другом сервере, который не является одним из двух серверов, которые вы используете. Как только сервер ответит, он изучит назначение port-mac и выполнит пересылку в asic. Это может быть особенно распространено на коммутаторах Cisco более низкого уровня.
Кроме того, есть ли у вас ACL для каждого порта? Это также может потребовать переключения ЦП, которое будет на порядки медленнее, чем в ASIC. Возникает ли у вас такая же проблема при запуске эхо-запросов, когда первый эхо-запрос имеет задержку 100 мс, а затем последующие эхо-запросы <1 мс? Если это коммутатор нижнего уровня, и он получает задержку только на tcp / ip, я бы проверил, нет ли ACL, который применяется к пакетам TCP / IP.
Я бы также проверил переключатель на загрузку ЦП, даже если он мало используется, если у него какая-то дурацкая конфигурация, которая заставляет его переключаться в ЦП, его легко можно перегрузить. Мы перегружали высокопроизводительные коммутаторы (транзитное соединение 10 Гбит / с) трафиком в диапазоне 100 Мбит / с, потому что мы непреднамеренно отправляли трафик, который должен был переключаться внутри ЦП.
Вы проверили кабели? Плохие кабели и / или пробивки могут привести к повторным попыткам, которые могут значительно увеличить задержку.
Это похоже на задержку, которую вы получите при переходе из одной части США в другую. Коммутатор управляемый? Можете ли вы подключиться к коммутатору и проверить наличие проблем? Я бы ожидал <1-2 мс в локальной сети
По моему опыту, коммутаторы Cisco должны вводить задержку менее 1 мс, так что да, это признак проблемы.
Оба устройства подключены к коммутатору с помощью проводов (т.е. не 802.11)? В той же VLAN?
Это надежная сеть? Если устройства и коммутаторы слегка загружены, я был бы обеспокоен тем, что кто-то использовал ARP-захват, чтобы вставить себя в поток трафика в качестве посредника ...
Если вы проверите таблицу ARP в этих полях (arp -an) и отметите IP-адрес другого поля с выводом ifconfig, совпадают ли MAC-адреса?
Вы упомянули, что анализируете вывод tcpdump. Вы сравниваете отметки времени между двумя полями? Если да, то уверены ли вы, что часы синхронизированы?
У вас есть доступ к третьему хосту в сети, чтобы сравнить производительность с двумя другими устройствами?
