Добрый день .

Сегодня установил, что на DES-3000 Series, на разных прошивках есть проблема с ограничением скорости на порту.

А именно ограничение RX ограничивает полосу не корректно, хотя TX работает замечательно.

Схема тестирования:
берем коммутоатор DES-3026 (можно и DES-3018) ограничиваем два порта, только по RX скажем до 800 килобит, к комутатору подключаем два компьютера, и с помощью iperf произодим тестирование пропускной способности между ограниченными портами. Если тестирование производиться по TCP, то реальная пропускная способность между портами будет как минимум в 4 раза меньше установленой на порту, однако если произвести тестирование - по UDP, то пропускная способность будет эквивалента установленной на порту.

Данная проблема была давно, только вот сегодня удлось выяснить настоящую причину.

Если от меня еще чего ни будь требуется - могу предоставить/протестировать.

_________________
WBR. Sp!ZER

Вообщемто эта проблема существует,
в доках указано, что если включить flow control, то проблема с tcp решается.
Но есть маленькая проблемка, бывают сетевые адаптеры, которые flow control не поддерживают.
В данном случае, проще шейпить 36-й серией потоки либо UNIX роутерами.

Странно но с flow control у меня по прежнему тоже самое.


Нереально менять коммутаторы серии 3000 их более 200 штук. Роутер Unix тоже не реально, так как вся сеть построена только на L2. Используются 3000 Серия, 35xx Серия и 38xx Серия.

_________________
WBR. Sp!ZER

Необходимо сделать следующее. На клиентских портах указать как TX так и RX одинаковыми и Flow Control включить. На сетевых картах также включить Flow Control. На порту uplink или сервера выключить Flow Control. Естественно и на другой стороне этого линка Flow Control надо выключить.

Необходимо указать только RX, так как ограничиваем исключительно upload. Указать RX/TX одновременно, мы сократим до минимума и download, что делать крайне не желательно. Далеко не все сетевые карты поддерживают 802.3x.
Как быть в такой ситуации?

Я тестировал Ваши коммутаторы, ограничение только по TX у Вас работет нормально TCP/UDP без всяких установок FlowControl. Хочеться того же самого на RX, но корректно работает только UDP. Такое ощущение что для RX/TCP выбран неверный алгоритм управления очередями (или там допущена ошибка).

_________________
WBR. Sp!ZER

2 Sp!ZER > После тщательных тестов данная проблема не обнаружена, я тестировал со входящим и исходящим трафиком TCP и UDP протоколов, во всех тестах всё нормально отрабатывалось. Пожалуйста, опишите подробнее как Вы тестировали, чтобы разобраться с данным случаем.

_________________
С уважением,
Бигаров Руслан.

1. Берем коммутатор. v 3.00.053
2. reset system (для простоты).
3. COS->Port Bandwith
3.1 PORT:8, TYPE:RX,NO_LIMIT: DISABLED,RATE:800
3.2 PORT:14, TYPE:RX,NO_LIMIT: DISABLED,RATE:800
4. Одна из сетевых карт не поддерживает 802.3x
5. тест по TCP
5.1. PORT:14 - iperf -s -i 10
5.2. PORT:8 - iperf -c xxx.xxx.xxx.xxx -i 10 -t 60
5.3. Результат измерения пропускной будет в районе 200 кбит.
6. тест по UDP
6.1. PORT:14 - iperf -s -i 10 -u
6.2. PORT:8 - iperf -c xxx.xxx.xxx.xxx -i 10 -t 60 -u
6.3. Результат измерения пропускной будет в районе 800 кбит.
7. тест по ICMP
7.1. PORT:14 - ping -f -s 1300 xxx.xxx.xxx.xxx
7.2. PORT:8 - iptraf -g & iftop -i eth0
7.3. при тестировании flood пингом была не значительная потеря данных (что вспринцепе вообще должно быть исключено), скорость в районе 900 кбит
8. тест FTP
8.1. PORT:14 - proftpd
8.2. PORT:8 - wget ftp://xxx.xxx.xxx.xxx/verybigfile.iso
8.3. закачка производилась рывками, скорость не привышала 200 кбит

Выводы таковы, что коммутатор, скорее всего, неправильно выстраивает очередь по TCP.

Если органичивать скорость порта не по RX, а по TX, то все будет работать нормально.

Если этой информации будет мало, могу скинуть конфиги и ревизии коммутаторов.

_________________
WBR. Sp!ZER

В этом случае мы не гарантируем нормальную работу функции Bandwidth Control.

_________________
С уважением,
Бигаров Руслан.

Замечательно. А как тогда быть? Почему то ни в документации, ни в UserGuide я такого не нашел.

Ну даже если так, то с использованием FlowControl, пропускная способность по TCP не в 4раза меньше а в два, и это все равно ниже того значения которое было выставлено в RX.

ИМХО тут дело не в 802.3x, а в алгоритме управления очередями (даже бросаеться в глаза)...

_________________
WBR. Sp!ZER

Это как аксиома, если Вы используете функцию Bandwidth Control, то на портах коммутатора и на сетевых адаптерах должна быть включена функция Flow Control.



Выше я уже писал, что провёл несколько тестов с Bandwidth Control на DES-3026 с TCP и UDP трафиком, как с синхронными, так и с асинхронными значениями Rx и Tx, и я на тестовом стенде проблему не наблюдал.

Вот мои результаты теста:

Настройки в CLI:

#config ports 14,20 speed auto flow_control enable state enable
#config bandwidth_control 14 rx_rate 10240 tx_rate 20480
#config bandwidth_control 20 rx_rate 20480 tx_rate 10240

Тест с UDP:

С 20 порта на 14 : 2451696 Byte per sec = 18,7 Mbps
С 14 порта на 20 : 1235397 Byte per sec = 9,43 Mbps

Тест с TCP:

С 20 порта на 14 : 0.0-10.0 sec 22.9 MBytes 19.2 Mbits/sec

Описанной вами, разницы в настроенной и реальной пропускной скорости я не наблюдаю в результатах теста.

_________________
С уважением,
Бигаров Руслан.

А как в этом варианте вы себе представляете вообще контроль входящей скорости на порту? Фактически у вас не остается никаких шансов управлять входящим трафиком если флоу контрол отсутствует. Вам остается одно дропать входящие данные, что для tcp приводит к перезапуску механизма плавающего окна. И скорость tcp потока будет зависеть от конкретной реализации стека tcp протоколов в ОС обменивающихся данными компьютеров.
Тоесть дошла до скорость, например, до максимума 800 килобит, коммутатор дропнул принятый пакет, tcp воспрнимат это как перегрузку и после таймаута начинает передачу с самого маленького окошка постепенно его увеличивая. И так в цикле. При использовании флоу контрол, свитч занимает полосу фактически мусором не давая передавать данные, дает пересылать только 800 килобит и все, никаких потерь пакетов не происходит, tcp решет правильно. Вот только бы объяснил мне кто как флоу контрол на полном дуплексе работает, у меня ощущение что никак

Можете проверить мою раскладки на своем порту гоняя десяток tcp потоков и смотря нагрузку на порту в свитче, скорее всего без флоу контрола будет резать в районе 800 килобит, т.к. потеря пары тройки пакетов будет означать падение скорости для одного - трех tcp потоков которые снизят скорость, при этом остальные займут свободную полосу.

У UDP же все проще и резать входящий трафик не составляет особого труда, отбрасываем лишние пакеты и все.

Ну кончено разницы не было, на одном из портов скорость TX ограничена в 10240. Т.е. порт уже не будет передавать данные на скорость более 10240. Вы ограничте только RX, а TX оставьте не лимитированным. И увидите что получиться ерунда.

_________________
WBR. Sp!ZER

Зачем отбрасывать, когда можно все выстроить в очередь и просто напросто увеличить задержку (медленный старт). Просто выбран не верный алгоритм управления очередями. У меня есть экземплер L2 коммутатора AT на котором есть Port Speed Control, и почему то не важно есть 802.3x нет 802.3x на сетевой карте, а ограничивает Rx/Tx замечательно.

_________________
WBR. Sp!ZER

В серии DES-30XX это аппаратное ограничение. Flow Control на клиентских портах должен быть включён. Вы с какой серией AT сравниваете?

AT-9410GB (Других Девайсов нет)

_________________
WBR. Sp!ZER