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

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

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

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

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

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

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

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

12 голосов | спросил Daniel Dib 1 FebruaryEurope/MoscowbSat, 01 Feb 2014 16:21:27 +0400000000pmSat, 01 Feb 2014 16:21:27 +040014 2014, 16:21:27

2 ответа


13

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

  

Почему был затронут только нисходящий поток, а не вверх по течению?

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

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

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

  

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

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

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

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

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


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

ответил YLearn 1 FebruaryEurope/MoscowbSat, 01 Feb 2014 20:25:28 +0400000000pmSat, 01 Feb 2014 20:25:28 +040014 2014, 20:25:28
2

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

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

ответил Łukasz Bromirski 1 FebruaryEurope/MoscowbSat, 01 Feb 2014 18:26:45 +0400000000pmSat, 01 Feb 2014 18:26:45 +040014 2014, 18:26:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132