Добрый день!

Имеется DGS-3100-24 с прошивкой 2.0.47

Замечена неприятная особенность.
Чтоб получить верное ограничение на входящий трафик, приходится указывать значение в 20 раз больше, чем требуемая скорость.
Т.е. нужен мегабит, приходится указывать 20000.

Flow control включен на юзерских портах???

_________________
LiveComm

да

Попробуйте, пожалуйста, с прошивкой, которую я Вам выслал, и сообщите о результатах

Видно что поменяли с rate_limit на bandwidth_control и появилось ограничение на исходящий с порта трафик
Но....исходящий с порта ограничивается нормально, а входящий - по прежнему в 20 раз меньше введёной цифры

Я протестирую эту ситуацию на тестовом стенде и по результатам Вам сообщу

На тестовом стенде проблемы обнаружить не удалось, при различных значениях rx и tx rate коммутатор вел себя корректно. Кроме того, не забывайте, что данная функция является не шейпером, а полисером. Попробуйте тестировать данную функцию программой iperf и обмениваться UDP пакетами, т.к. у TCP более сложная структура.

Дело в том, что при реальной работе клиента, чтоб обеспечить ограничение в мегабит, приходится прописывать 20000.
Думаю клиента будет не убедить перейти на работу с iperf по udp протоколу.
На других DLinkах (3010, 3018) всё работает согласно прописанному.

Как я уже говорил, это не шейпер, а полисер и, поэтому при использовании TCP трафика, указанное в настройках и реальное значение скорости могут не совпадать. В определённых случаях значение нужно подбирать экспериментально. Кроме того, не забывайте, что sh packet ports показывает данные в байтах, а не битах.

Денис, хочу вас заверить, что тот механизм, который сейчас функционирует в D-link, не имеет к полисеру (в общепринятом понимании) ни малейшего отношения.

Вот в картинках работа полисера и шейпера:
http://www.cisco.com/en/US/tech/tk543/t ... 3a25.shtml

Полисер может может "срезать" пакет размером в 1000 байт, если до границы, которая была в нем установлена, остается только 999 байт и нет burst-a, но при этом пропустит пакеты до 999 байт включительно.

Те ситуации, которые многократно описываются пользователями на форуме, имеют следующую картину: при установленных 10Мбит/с на порту на вход, в результате получаем порядка 1Мбит/с TCP трафика. Но, опять же, - TCP или UDP - не имеет ни малейшего значения (как по логике, так и по факту, поскольку обращения пользователей происходят в отношении L2 коммутаторов, а не L3)

Так вот, получение 1Мбит/с трафика при установленном ограничении в 10Мбит/с - это не работа полисера, это баг, который отсутствует даже в Planet (и это с его-то перманентной неадекватностью) и от признания которого D-Link пытается открещиваться

Почему подобная досадная ошибка не исправлена в коммутаторах D-Link, для меня лично - загадка. Еще большей загадкой является столь ярое нежелание признавать наличие проблемы

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

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

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

Если вы всё же настаиваете на предоставлении данных, конфигов и результатов тестов, могу воссоздать проблему на 3028/3526 (благо, их много, а проблема одинаково воспроизводится на 3028/3526/3100/3200). Могу отписать по 3028/3526 в соответствующей теме.

по части невозможности воссоздания проблемы на стенде...



Денис описал наличие проблемы и зафиксировал ее, т.е. данные у вас по проблеме есть. Вот только подобное поведение полисера в контексте тестов почему-то рассматривается как нормальное с предложением "подбирать экспериментально" значения полисера под TCP трафик.

Но есть ряд довольно важных моментов:
- подбирать экспериментально прийдется не в определенных случаях, а в 100% случаев (или получается, что все пользователи попадают как раз в эти "определенные случаи"). Но это не суть важно. Главное - фиксируете проблему;
- отличие установленного значения от фактической скорости по порту отличается в разы (до 10 раз);
- после "подбора" UDP трафик по каналу сможет проходить на установленной скорости, которая значительно будет отличаться от той, которая будет получена на TCP трафике в результате подбора значений полисера (например, 1Мбит/с TCP трафика на значении полисера в 10Мбит/с, но при этом же UDP трафик будет проходить на скорости 10Мбит/с).

Именно это и есть проблема и именно на этот факт пользователи пытаются обратить внимание представителей D-link, поскольку не нормально поведение полисера, когда его работа зависит от того, какой протокол идет по каналу.

Руслан, согласитесь, ну подобрал экспериментально, допустим, пользователь ограничение по трафику в 10Мбит/с, чтобы получить 1Мбит/с на TCP трафике - не вопрос. Но UDP-то трафика при этом будет принято 10Мбит/с. Где ограничение трафика? Если канал устанавливается на 10Мбит/с, то там и должно быть 10Мбит/с любого протокола, хоть TCP, хоть UDP.

Если полисер при подсчете работает с длиной payload, а не длиной фрейма (на что, возможно, были причины, хоть и не дело это для L2 коммутатора ковыряться в протоколах) и корректно производит обработку UDP, то всё, что необходимо, - корректно обрабатывать длину payload в TCP пакете. На текущий момент, поведение полисера наталкивает как раз на мысли о том, что проблема как раз в этом (поскольку проблема зависит от типа протокола)

Укажите пожалуйста в личку Ваш телефон. И вот на это обратите внимание
Drops excess packets (when configured), throttling TCP window sizes and reducing the overall output rate of affected traffic streams. Overly aggressive burst sizes may lead to excess packet drops and throttle the overall output rate, particularly with TCP-based flows.

отправлен



то, что параметры полисера будут иметь влияние на трафик (не только на TCP) - по этому вопросов (или непонимания) нет. Но одно дело, - "недостача" 10% от выставленного ограничения на некорректных burst-ах, другое - 90%.

Кстати, в коммутаторах D-link, если уже говорить о параметрах полисера, отсутствует возможность их изменения пользователем. Возможно, конечно, оно и к лучшему, но всё же даже некорректный параметр - не вина человека, который настраивает коммутатор, поскольку он не имеет контроля над этими параметрами

В случае с Cisco, существует формула, которая рекомендуется производителем для высчитывания параметров полисера:
normal burst = скорость включения /(8 бит) * 1.5 секунд
extended burst = 2 * normal burst

Формула - далеко не панацея и производителем дана с большим запасом, но суть сводится к тому, что на любом типе трафика при выставленных 10Мбит/с ограничения скорости, пользователь получит свои 10Мбит/с. В ряде случаев (на определенных типах и интенсивности трафика), возможно получение пользователем 11мбит/с. Но речь идет лишь о том, что на всплеске возможен перебор 10%, которые можно "списать" в интересах качественного предоставления сервиса клиенту. Но здесь хоть понятны порядки возможных внеплановых всплесков. В текущей же теме говорится о необходимости подбора и недоборе трафика от выставленных значений в намного больших цифрах.

Про тонкие настройки это в какой серии Cisco?