Switchport в полудуплексном режиме - скорость загрузки страдает, но загрузка прошла нормально

13

У пользователя возникли проблемы со скоростью загрузки из Интернета. Подключение к интернету 100 Мбит / с. Пользователь получил около 7 Мбит / с вниз по течению и около 80 Мбит / с вверх по течению.

Я проверил со своего компьютера, и он получил около 70 Мбит / с нисходящего и 80 Мбит / с восходящего. Очевидно, что пользователи ПК были виноваты.

Я проверил коммутатор, который является Catalyst 3560, и там это было, как я ожидал, порт был в полудуплексном режиме. Пользователь жестко запрограммировал свой ПК на 100 / full, и порт использовал auto. Скорость определяется импульсами быстрой связи (FLP), но дуплекс должен быть принят равным половине, поэтому порт использовал 100 / половину. С show controller я мог видеть столкновения и поздние столкновения, как и ожидалось.

Пропускная способность была проверена на шведском сайте www.bredbandskollen.se. Сначала он использует TCP для проверки задержки. Затем он открывает сокет через Flash и выполняет несколько HTTP GET (TCP) и измеряет пропускную способность нисходящего потока в течение примерно 10 секунд. После этого он отправляет четыре HTTP-сообщения на сервер, отправляет трафик в течение 10 секунд и вычисляет пропускную способность восходящего канала.

Я знаю, что такого рода сайты не являются на 100% точными, но обычно они могут по крайней мере дать какое-то указание, если вы близки к получению того типа полосы пропускания, который вам нужен, и это был простой тест, чтобы убедиться, что это пользователь, а не сеть виновата здесь.

  1. Почему был затронут только нижний поток, а не верхний?

  2. Это настоящие столкновения? Поскольку кабель имеет отдельные пары передачи и приема.

Даниэль Диб
источник
70/80 основаны на одном тесте или среднем за несколько тестов? Учитывая изменяющийся размер окна, один тест будет слишком расплывчатым.
user2964971

Ответы:

14

Это совершенно нормальное поведение с несоответствием дуплекса.

Почему был затронут только нижний поток, а не верхний?

Поскольку компьютер работает в дуплексном режиме, он не использует CSMA-CD. Это означает, что он не проверяет, простаивает ли среда перед передачей, и не будет воспринимать любые данные, которые он получает во время передачи, как столкновение. Таким образом, загрузка с компьютера останется практически неизменной.

Наоборот, коммутатор использует CSMA-CD и будет ожидать, пока носитель не будет работать, прежде чем он передаст. Кроме того, когда коммутатор обнаруживает коллизию, он немедленно прекращает передачу кадра и следует процедуре обнаружения коллизии CSMA-CD. Это существенно влияет на производительность, передаваемую на компьютер.

Когда трафик TCP, отрицательный эффект будет умножен, так как любой потерянный TCP ACK, поступающий на компьютер, вызовет повторную передачу TCP.

Это настоящие столкновения? Поскольку кабель имеет отдельные пары передачи и приема.

Да, они настоящие столкновения; даже в полудуплексной среде (т. е. концентраторах) существуют отдельные пары передачи и приема. Причина в том, что в полудуплексной среде концентраторы будут повторять сигнал, полученный на один порт, через все другие порты. Если две станции будут пытаться передавать одновременно, повторяющийся сигнал не будет использоваться.

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

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

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


Кроме того, это наиболее часто сообщаемый тип несоответствия дуплексных режимов (когда переключатель установлен в автоматический режим, а компьютер - в полный дуплексный режим). Большинство людей загружают гораздо больше, чем загружают, и им легче заметить это состояние, чтобы сообщить об этом.

YLearn
источник
2
Мне потребовалось некоторое время, чтобы понять вашу точку зрения на вопрос о разнице в скорости, но это хороший ответ ... вы можете улучшить его, чтобы явно указать, что Tx коммутатора ограничен по скорости больше, чем ПК, потому что он должен ожидайте дольше из-за обнаружения коллизий CSMA / CD, чем ПК будет ожидать прогнивших кадров от коллизий. И наоборот, если даже несколько TCP ACK ПК сталкиваются при загрузке с ПК, загрузка подвергается двойному штрафу как по TCP, так и по CSMA / CD Ethernet. Отброшенные TCP ACK замедляют обе передачи, но откат CSMA / CD убивает загрузку.
Майк Пеннингтон
Это также зависит от того, какой конец является полным, а какой - половинным. Полный отправляет / получает без проблем, в то время как другой будет видеть коллизию для каждого пакета. Это означает, что передача данных с полного конца вызовет меньшую коллизию на половинном конце ( так как половина конца будет пытаться сжать ACK между большими пакетами), а наоборот, полная сторона вызовет много коллизий, потому что у нее больше шансов «ударить» большой пакет с меньшим подтверждением. Возможно, это не правильное объяснение, но оно соответствует тому, что я видел.
Реми Летурно,
@RemiLetourneau, ясно, что если направление несоответствия должно быть обращено вспять, эффект также будет обратным. В таком случае вы можете поменять местами компьютер / термины в моем ответе (который был рамкой для ответа на вопрос ОП). Не уверен, что я следую всем остальным вашим комментариям, хотя.
YLearn
@YLearn То, что я хотел сказать, это то, что симптомы несоответствия дуплекса включают трафик, движущийся с относительно нормальной скоростью в одну сторону и замедляющийся, чтобы ползти наоборот. Что-то, что нужно сделать, когда отправлять большие кадры, а конец - отправлять подтверждение. Как вы говорите, если вы измените конфигурацию несоответствия, вы поменяете медлительность трафика.
Реми Летурно,
3

Если TCP был протестирован, есть много вещей, которые вы не можете контролировать или даже представить. Разница в нисходящем / восходящем направлении может быть легко вызвана внутренними настройками приоритетов NIC, буферами для RX / TX и, по существу, низкоуровневыми настройками, которые определяют способ обработки трафика RX и TX.

Контроллеры sh должны сообщать обо всех одновременных состояниях RX и TX как о столкновении, если они работают в полудуплексном режиме.

Лукаш Бромирски
источник