Нисходящая линия связи моего моста D-Link стала медленнее в 10-30 раз?


2

TL; DR: Я отсоединил свою сеть, чтобы переместить мой стол, и теперь загрузка через мост локальной сети Ethernet моего DIR-655 в 10-30 раз медленнее, чем у коммутатора Ethernet, к которому он подключен.

Фон

Моя сеть

SMC cable modem <-> Cisco firewall <-> Netgear switch <-> D-Link WiFi†
     |                    |                 |                  |
 SMC8014               ASA-5505         GS608v2 gigE      DIR-655 rev A3 gigE

† DIR-655 используется в качестве точки доступа, а не маршрутизатора (хотя что D-Link вызывает точку доступа, я бы назвал мост). Порт WAN неиспользованный; Netgear подключается к встроенной 4-портовой локальной сети Ethernet Переключатель внутри встроенного маршрутизатора / брандмауэра.

Endpoints:

  • MacBook Pro 17 "середина 2010 года
  • Айфон 4С
  • Linux-сервер Fedora 12, работающий на достаточно быстрых платформах Dual-Athlon X2, VelociRaptors и т. Д.

Все кабели длиной менее 10 футов, в основном CAT-5e, некоторые CAT-6, все готовые. Все конечные точки WiFi находятся в пределах трех футов от D-Link.

Вчера я отсоединил и переставил вещи, и теперь подключение через D-Link - даже через проводной коммутатор, прямо рядом с входящим сетевым кабелем - в 30 раз медленнее, чем подключение напрямую к коммутатору Netgear, на моем MacBook и iPhone.

Как я измеряю "медленнее"

Я в основном использую http://speedtest.net , который, конечно, только измеряет широкополосные скорости Я также установил http://www.speedtest.net/mini.php на моем локальном сервере, но не могу проверить iPhone с этим.

Результаты

Speedtest.net, closest server over Comcast business-class:

CONFIG                           | PING (ms)   | DOWN (Mbps)   | UP (Mbps)
Mac    <-> Ethernet <-> Netgear  |  9          | 31.6          |  6.8 
Mac    <-> Ethernet <-> D-Link   |  8          |  4.1          |  6.0
Mac    <-> WiFi     <-> D-Link   |  9          |  1.4          |  2.9
iPhone <-> WiFi     <-> D-Link   | 67          |  0.4          |  1.6

Speedtest Mini on Linux PC:

CONFIG                                         | DOWN (Mbps)   | UP (Mbps)
Mac    <-> Ethernet <-> NetGear                | 97.2          | 76.9
Mac    <-> Ethernet <-> D-Link                 |  8.2          | 24.2
Mac    <-> WiFi     <-> D-Link                 |  1.0          |  8.6

Slow typing in SSH:

Mac    <-> Ethernet <-> Netgear <-> Linux PC: smooth
Mac    <-> Ethernet <-> D-Link  <-> Linux PC: choppy

Обратите внимание, что скорость загрузки D-Link нормальна для широкополосной связи, локально медленнее (но я считаю, что это ограничение D-Link) и всегда быстрее, чем загрузка! Так как ssh изменчив только из-за медленной типизации, я не верю, что это проблема типа дросселирования; это не много пропускной способности.

Что я пробовал

  • Обмен всех "хороших" и "плохих" кабелей
  • Повторно подключите «плохой» кабель от D-Link к Netgear и посмотрите, будет ли он «хорошим» кабелем
  • отсоединение кабелей от линий электропередач
  • Убедитесь, что Mac автоматически обнаруживает D-Link как сигнал
  • Попробуйте проверить скорость соединения D-Link & lt; - & gt; Netgear соединение, но прошивка не сообщает, что
  • Убедитесь, что D-Link не видит ошибок или коллизий TX / RX
  • Используйте разные порты Ethernet на Netgear и D-Link
  • Сбросить D-Link к заводским настройкам
  • Обновите прошивку D-Link с 1.21 до 1.35NA, 2010/11/12, последняя
  • Перезагрузите все хотя бы один раз
  • На Mac отключите Wi-Fi во время тестов Ethernet и отключите Ethernet во время тестов Wi-Fi
  • Используя iStumbler, убедитесь, что D-Link не выбирает перегруженные каналы Wi-Fi (обычно только 1-5 соседей на моем и соседних каналах, в среднем для моего подходящего здания)
  • Убедитесь, что единственным клиентом, подключенным к Wi-Fi, был iPhone
  • Убедитесь, что в моей сети ничего не болтало согласно журналу WISH
  • Включите и отключите все виды настроек D-Link, включая принудительное автоматическое обнаружение WAN для работы

Так.

Я не против купить новую точку доступа - я не против иметь сеть с двумя каналами - но как парень, который работал в сети с gated v4, был коренным образом переписан, и который часто использовал физические снифферы во времена перед Wireshark, Я сбит с толку. Я ненавижу быть сбитым с толку.

Что я мог возможно изменились, что приведет к этому? Как я могу это измерить? Все, о чем я могу думать, - это статический удар - толстый ковер, носки, HVAC - но я не чувствовал его, и это действительно происходит больше?

Могу ли я проверить, медлительность ли это уровня Ethernet или TCP? Я не знаком с современными сетевыми утилитами; Google трудно, не нажимая кнопку «В: Почему моя сеть работает медленно?

Если я не получу ответ здесь, поможет ли кто-нибудь крупный и влиятельный перенести его на serverfault, не возвращаясь сюда? По словам Иниго Монтойи: «Я должен знаю. "Не берите на меня всех ужасных пиратов Робертса.

Ответы:


1

У меня была похожая проблема с коммутатором netgear, у которого был порт "uplink", который фактически был разделен между двумя интерфейсами. Если вы подключите что-либо к порту рядом с восходящей линией связи, скорость упадет на порядок. У меня тоже есть значительный опыт работы с сетью, поэтому я выбрал tcpdump и действительно переоценил его.

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

К сожалению, я не уверен, есть ли у них ethtool или mii-tool или стандартные инструменты * nix t-shoot.

Быстродействующий SSH звучит как алгоритм nagles или проблема типа медленного старта, медленно выпускающая пакеты в сеть. Вы подтвердили, что на самом деле нет перегрузки сети?

Это звучит так же, как проблема, которую я имел.


Какой хороший способ подтвердить отсутствие перегрузки сети? Я предположил, что в современной коммутируемой сети (без других клиентов!) Их просто не будет. Я схватил точку доступа D-Link DAP-1522, и она работает нормально, но мне все еще интересно ...
Jay Levitt
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.