Обнаружились странности в работе HOL prevention.
Есть схема: DES-3528. В 25-ый порт включен трафикогенератор, линк 1G/FD/no-FC. В 23-ий включен свич1, в 24-ый - свич2, линки 100Mb/FD/no-FC. На 23-й порт в FDB прописан мак1, на 24-ый - мак2. Порты 23-25 в одном влане, без тега. Свичи в 23-24 портах используются только для поднятия линков.
С трафикогенератора запускаем одновременно два потока:
1. iperf -c 10.0.0.2 -u -b 90M -t 20
2. iperf -c 10.0.0.3 -u -b 90M -t 20
Первый поток, залетая в 25-ый порт, вылетает из 24-го. Второй - из 23-го.
Итак, потоки 90 и 90 мегабит: FW 2.01.B042 - потери первого потока 10%. FW 2.60.017 - 36%
Потоки 80 и 1 мегабит: 2.01 - 4%, 2.60 - 32%
Потоки 40 и 40 мегабит: потери 0%
При выключении HOL prevention на обоих прошивка при потоках 90 и 90 мегабит потерь нет.
Это что ж там за алгоритм такой, который такой эффект дает? К тому же, HOL prevention вроде как должен работать в случаях many-to-one, а тут обратная ситуация. Ну и в 2.60.017 результат просто ужасающий. Как и чем лечить?

Нет идей? Может в новых бетах алгоритм меняли?

Я отпишу в ШК по данной проблеме.

Пришлите мне ваши результаты теста на почту при выключенном и включенном HOL prevention.
Необходимы скриншоты iperf'a в обоих случаях а также вывод команды show error ports с коммутатора.

Проблема есть но не так уже все плохо как написано, может так и должно работать. стенд: один 3528 с прошивкой 2.63.B029 (перед этим дал reset sys f). В 26 порт подключаем ПК (172.31.0.3) с GE интерфейсом и запускаем два сеанса командной строки:
iperf -c 172.31.0.1 -u -p 10001 -b 90M -t 600 -i 5
iperf -c 172.31.0.2 -u -p 10002 -b 90M -t 600 -i 5
в два FE подключаем по клиенту и запускаем на каждом, соответственно по адресу
c:/iperf -s -u -i 10 -p 10001 на компе 172.31.0.1
c:/iperf -s -u -i 10 -p 10002 на компе 172.31.0.2

Вот что видно в iperf на одном из FE портов
dis hol
[1172] 10.0-20.0 sec 107 MBytes 89.8 Mbits/sec 0.001 ms 578/76925 (0.75%)
[1172] 20.0-30.0 sec 107 MBytes 89.8 Mbits/sec 0.001 ms 585/76923 (0.76%)
[1172] 30.0-40.0 sec 107 MBytes 89.7 Mbits/sec 0.001 ms 607/76923 (0.79%)
[1172] 40.0-50.0 sec 107 MBytes 89.6 Mbits/sec 0.001 ms 713/76924 (0.93%)
[1172] 50.0-60.0 sec 107 MBytes 89.5 Mbits/sec 0.001 ms 801/76923 (1%)
[1172] 60.0-70.0 sec 106 MBytes 89.3 Mbits/sec 0.001 ms 888/76804 (1.2%)
[1172] 70.0-80.0 sec 107 MBytes 89.6 Mbits/sec 0.001 ms 763/76924 (0.99%)
[1172] 80.0-90.0 sec 107 MBytes 89.4 Mbits/sec 0.001 ms 927/76923 (1.2%)
[1172] 90.0-100.0 sec 107 MBytes 89.7 Mbits/sec 0.001 ms 675/76924 (0.88%)
en hol
[1172] 100.0-110.0 sec 105 MBytes 87.8 Mbits/sec 0.001 ms 2102/76804 (2.7%)
[1172] 110.0-120.0 sec 105 MBytes 87.7 Mbits/sec 0.001 ms 2380/76923 (3.1%)
[1172] 120.0-130.0 sec 103 MBytes 86.1 Mbits/sec 0.001 ms 3583/76804 (4.7%)
[1172] 130.0-140.0 sec 104 MBytes 87.3 Mbits/sec 0.001 ms 2659/76923 (3.5%)
[1172] 140.0-150.0 sec 105 MBytes 87.9 Mbits/sec 0.001 ms 2141/76925 (2.8%)
[1172] 150.0-160.0 sec 105 MBytes 87.9 Mbits/sec 0.005 ms 2091/76801 (2.7%)
[1172] 160.0-170.0 sec 105 MBytes 88.0 Mbits/sec 0.001 ms 2094/76925 (2.7%)
[1172] 170.0-180.0 sec 105 MBytes 87.8 Mbits/sec 0.001 ms 2239/76924 (2.9%)
[1172] 180.0-190.0 sec 104 MBytes 87.5 Mbits/sec 0.001 ms 2495/76924 (3.2%)
dis hol
[1172] 190.0-200.0 sec 107 MBytes 89.6 Mbits/sec 0.001 ms 692/76923 (0.9%)
[1172] 200.0-210.0 sec 107 MBytes 89.8 Mbits/sec 0.001 ms 585/76924 (0.76%)
[1172] 210.0-220.0 sec 107 MBytes 89.7 Mbits/sec 0.001 ms 644/76922 (0.84%)
[1172] 220.0-230.0 sec 107 MBytes 89.6 Mbits/sec 0.001 ms 654/76805 (0.85%)
[1172] 230.0-240.0 sec 107 MBytes 89.7 Mbits/sec 0.001 ms 635/76922 (0.83%)
[1172] 240.0-250.0 sec 107 MBytes 89.4 Mbits/sec 0.001 ms 915/76924 (1.2%)
[1172] 250.0-260.0 sec 107 MBytes 89.7 Mbits/sec 0.001 ms 634/76923 (0.82%)
[1172] 260.0-270.0 sec 107 MBytes 89.8 Mbits/sec 0.001 ms 583/76923 (0.76%)

На втором аналогично.

Вот счетчики:
Сначала обнулил и с выключенным hol не росли и были по нулям. после включения hol стали увеличиваться на GE
Port Number : 26
RX Frames TX Frames
--------- ---------
CRC Error 0 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 0 Late Collision 0
Fragment 0 Excessive Collision 0
Jabber 0 Single Collision 0
Drop Pkts 45123 Collision 0
Symbol Error 0

На клиентских портах по нулям.
Выключил HOL счетчики перестали повышаться.

В целом потери есть но не такие большие. Поэтому пока расписывать по всей отключение hol не буду. Жду комментариев D-Link.

Ivan E.
В том то и дело, что лабораторные результаты больше походят на ваши результаты, чем на результаты XLighter.

Потери что в одном что в другом случае или нулевые, или меньше процента.
Жду комментариев и скриншотов со стороны XLighter.

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

PS Процент потерь больше одного

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

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

Получилось ли повторить проблему?

ШК ответила что нибудь по поводу дропов?

up

Я уже отписал, что дропов в 30% получить не удалось. И подробного описания, как это сделать, я так и не дождался.
Потери в 0,5%-1% на загруженном гигабитном канале могут быть взваны проседанием производительности сетевой карточки.
В синтетических тестах что при включенном, что при выключенном HOL Prevention потерь нет.

Загрузка на гигабитном канале в 180 мегабит вызывает потери... Я собирал стенд, были потери, прочитайте внимательно мой пост. При включенном hol коммутатор показывал дроп пакетов, при выключенном - нет дропа.

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