Странное поведение Ingress limit при скорости порта 1000 Мбит/с

[san]

Установка значения ограничения Ingress limit rate менее 50 Мбит/с при скорости порта 1000 Мбит/с приводит к нарушению связности.

1. подключил к Ethernet порту 8 платы Sw-01 компьютер (скорость порта 1000 Мбит/с)
2. Запустил пинг(64 байта раз в секунду) на этот компьютер с другого компьютера, находящегося со стороны другого порта платы SW-01
3. В настройках порта 8 платы SW-01 я установил чекбокс Ingress rate limit->Limit known unicast.
4. При установке значения Limit: более примерно 50 000 kbit/s пинг проходит. При установке значение меньше (например 30 000 kbit/s) - пинг не проходит.

p.s. установил высокий приоритет тикета, т.к. "на носу" отгрузка схемы где используется эта настройка.

[alx]

Вот здесь написано, как сделать хороший баг-рипорт. Если кратко, хороший баг-рипорт состоит из трех основных компонентов: что делали, что ожидали получить в результате и что получили вместо ожидаемого. В данном тикете, к сожалению, описано только что делали и что получили в результате. Судя по тому, что тип тикета установлен в значение "баг", я догадываюсь, что получен не тот результат, который ожидался, однако какой именно результат ожидался, не написано. В результате я пока не могу понять, в чем же по твоему мнению состоит баг. Уточни, пожалуйста.

[san]

Ожидалось, что настройка Ingress rate limit устанавливает ограничение ширины полосы входящего в порт трафика и что установка значения ограничения в 30 Мбит/с не должна привести к нарушению связности между компьютерами.

[alx]

Спасибо за уточнения.

За включение Ingress rate limit порта 8 для known unicast отвечает бит 4 регистра 0x02008000 коммутатора. Я провел проверку: после установки указанного чекбокса из регистра читается 0x10 (бит 4 установлен), после снятия - 0x00 (бит 4 сброшен).

Величина ограничения ingress rate порта 8 устанавливается битами 5...20 регистра 0x02008010 коммутатора. Единица измерения лимита - 51.2 кбит/с.

После задания значения 50000 кбит/с из регистра читается значение 0x00007a20. Биты 5...20 содержат значение 0x3d1 или 977, что дает значение ограничения (977 * 51.2) = 50022.4 кбит/с.

После задания значения 30000 кбит/с из регистра читается значение 0x00004940. Биты 5...20 содержат значение 0x24a или 586, что дает значение ограничения (586 * 51.2) = 30003.2 кбит/с.

Насколько я вижу, значения в регистрах коммутатора соответствуют заданной конфигурации.

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

Ошибок в описанном поведении не вижу, вынужден закрыть тикет.

[san]

Подтверждаю. Воспроизвести описанное не удалось, видимо в эксперименте была ошибка.

[san]

Повторил эксперимент в месте проявления бага. Баг проявился.
Заметил, что обязательное условие проявления бага - скорость порта 1000 Мбит/с.

1. Подключил два компьютера к портам платы SW-01 (один из них к порту 8, скорость порта 1000 Мбит/с)
2. Запустил пинг между компьютерами - наблюдаю обмен данными (трафик между портами порядка 10-20 кбит/с)
3. Установил все чекбоксы в настройке Ingress limit, задал rate=800 кбит/с.
4. Через несколько секунд после применения настройки связность между компьютерами потерялась (пинг перестал проходить) - так быть не должно.
5. Установил скорость порта компьютера подключенного к порту 8 в 100 Мбит/с., связность между компьютерами появилась.

[alx]

Replying to san:

4. Через несколько секунд после применения настройки связность между компьютерами потерялась (пинг перестал проходить) - так быть не должно.

Ты ошибаешься. Именно так и работает ограничение скорости. Я уже писал об этом в comment:4. Повторяю: поскольку ограничение полосы пропускания производится путем уничтожения пакетов, нарушение связности при наличии ограничения является нормальным явлением.

[san]

Хм... наверное я недостаточно точно выразился.
Нарушение связности не было кратковременным, я ожидал минуты и связность не восстановилась.
При этом объём трафика между компьютерами был на порядок меньше значения установленного лимита.
Явно это не нормальное поведение.

Повторю, что описанное явление проявляется только на скорости порта 1000 Мбит/c, а при установке скорости порта 10/100 Мбит/с, установка лимита работает согласно ожиданиям. В даташите на коммутатор написано что для каждой скорости порта есть свой регистр настроек "window time", подозреваю что в регистр 0x02040140 пишется что-то не то....

[alx]

Replying to san:

Нарушение связности не было кратковременным, я ожидал минуты и связность не восстановилась.

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

При чем тут кратковременность или долговременность я не понимаю. Ограничение трафика должно действовать сколько угодно долго, до тех пор, пока оно не будет отключено настройками.

При этом объём трафика между компьютерами был на порядок меньше значения установленного лимита.

Имеется в виду трафик между компьютерами, выполняющими пинг? Если да, то этого недостаточно чтобы предполагать, что ограничение не должно действовать. В порт 8 мог поступать трафик, адресованный другим хостам, и при этом быть на порядок больше трафика ping...

Явно это не нормальное поведение.
Повторю, что описанное явление проявляется только на скорости порта 1000 Мбит/c, а при установке скорости порта 10/100 Мбит/с, установка лимита работает согласно ожиданиям.

Это как? Пакеты не пропадают? Если да, то это как раз означает, что ограничение не действует...

В даташите на коммутатор написано что для каждой скорости порта есть свой регистр настроек "window time", подозреваю что в регистр 0x02040140 пишется что-то не то....

Это нетрудно проверить:

root@sw01:~# phyctl readdx 0x02040140
0x02040140: 0x04c26026

Как видим, размер окна для всех трех скоростей имеет значение 0x026, что соответствует (38 * 0.256 мс) = 10 мс.

[san]

Replying to alx:

Возможно, мы о разном говорим

Попробую ещё раз.
Я знаю, что трафик между портами учавствующими в эксперименте в пределах 30 кбит/с.
Я установил ограничение 800 Кбит/с и ожидал что пакеты не будут пропадать, т.к. ограничение значительно больше чем требуется для прохождения всего трафика. Однако пинг перестал проходить.
В одних и тех же условиях:

• без установки ограничения - пинг проходит.
• при скорости порта 10 или 100 и установке лимита 800 кбит/с - пинг проходит.
• при скорости порта 1000 и установке лимита 800 кбит/с - пинг не проходит

[alx]

Replying to san:

Я знаю, что трафик между портами учавствующими в эксперименте в пределах 30 кбит/с.

Это опять не очень понятно - что значит "между портами"? Учитывается любой трафик, входящий в порт 8, независимо от его вида и последующего назначения.

Я установил ограничение 800 Кбит/с и ожидал что пакеты не будут пропадать, т.к. ограничение значительно больше чем требуется для прохождения всего трафика.

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

В одних и тех же условиях:

• без установки ограничения - пинг проходит.
• при скорости порта 10 или 100 и установке лимита 800 кбит/с - пинг проходит.
• при скорости порта 1000 и установке лимита 800 кбит/с - пинг не проходит

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

С другой стороны, даже если это так, мы вряд ли что-то можем с этим сделать, так как ограничение выполняет коммутатор, а мы можем только косвенно управлять этим процессом, изменяя настройки.

Попробую перечитать описание функции, может быть это наведет на какие-нибудь мысли...

[san]

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

Верно.

С другой стороны, даже если это так, мы вряд ли что-то можем с этим сделать, так как ограничение выполняет коммутатор, а мы можем только косвенно управлять этим процессом, изменяя настройки.

В первом эксперименте у меня сложилось впечатление, что что-то не так со значением лимита, т.к. при установке магической цифры 50 000 в качестве лимита, пакеты таки начинали проходить.

Попробую повторить эксперимент и показать тебе этот эффект вживую...

[alx]

Перечитал описание функции. Есть очевидный случай, когда все передаваемые компьютером кадры будут уничтожаться - когда размер пакета (включая преамбулу и флаги) превышает 586 байт. В этом случае первый же принятый пакет превысит установленный лимит и будет уничтожен коммутатором (что правильно). Однако, во-первых, ты пишешь, что размер пакета - 64 байта. Даже если это - размер пакета IP, после добавления 18 байт заголовка ethernet, 4 байт CRC и 20 байт преамбулы/SFD/IPG получается 106 байт, что намного меньше 586. А во-вторых, ограничение должно работать одинаково при любой скорости...

У меня нет объяснения наблюдаемому эффекту.

Для чистоты эксперимента:

1. Можешь ли ты подтвердить с помощью tcpdump, что из компьютера в сеть не передается ничего "лишнего" кроме запросов ping размером 64 байта раз в секунду?
2. Можешь ли ты отключить ограничение любого трафика кроме known unicast и убедиться, что ситуация по-прежнему воспроизводится?
3. Можешь ли ты установить в 1 бит 11 регистра 0x02008000 (разрешение инкремента счетчика отброшенных пакетов) и убедиться, что счетчик увеличивается (для этого надо сначала прочитать регистр 0x02040148, затем регистр 0x0204014c)?
4. Если счетчик действительно увеличивается, можно почитать регистр 0x02008400 - текущее значение счетчика байт порта 8...

[san]

Я думаю будет проще без посредника, в лице меня, провести экперименты, поэтому я собрал схему:

Как будет время и желание - можешь потыкать её палочкой.

• "Испытуемый" порт обозначен красным.
• Пингую из нашей сети удаленный ПК 192.168.20.70
• Скорость испытуемого порта изменяю с помощью настройки "противоположной стороны" (порта 1 GE-12)

Гарантировано баг воспроизводится при следующих условиях:

• испытуемый порт установил соединение на скорости 1000 Мбит/с
• в настройке Ingress limit rate установлены все чекбоксы и rate= 9984

[san]

при установке магической цифры 50 000 в качестве лимита, пакеты таки начинали проходить.

Вот это не совсем так, при установке значений >50000 в качестве лимита вроде бы сначала всё работает, а потом через некоторое время вдруг пинг пропадает.

[alx]

Replying to san:

при установке магической цифры 50 000 в качестве лимита, пакеты таки начинали проходить.

Вот это не совсем так, при установке значений >50000 в качестве лимита вроде бы сначала всё работает, а потом через некоторое время вдруг пинг пропадает.

Это очень странно и наводит на мысль, что что-то все-таки не так с методикой эксперимента. Согласно описанию функции, коммутатор не должен помнить предысторию больше размера окна, то есть в нашем случае дольше 10 мс...

Попробую попинговать, о результатах расскажу.

[alx]

Отвечаю на свои собственные вопросы из comment:13:

1. Нет, подтвердить не могу. Судя по счетчикам порта, компьютер по собственной инициативе (без запросов ping) периодически посылает какие-то юникастовые пакеты. Это говорит о том, что эксперимент нельзя считать "чистым".

2. Да, воспроизводится.

3. Да, счетчик увеличивается и довольно быстро - около 80 пакетов за секунду. Если ping'а нет, счетчик не увеличивается.

4. Из регистра 0x02008400 читается значение 0x003fffef. Оно не изменяется независимо от наличия или отсутствия ping'а. Похоже, что счетчик не сбрасывается в 0 по окончании окна, как это описано в документации.

Я не знаю, что тут можно сделать.

[alx]

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

[san]

Хочется понять, как с этим мириться)
Т.к. ограничение трафика довольно востребованная функция (по статистике вопросов от пользователей) я планировал протестировать эту настройки и описать в РЭ.
А с наличием такого бага, я даже не знаю что и делать, опасная получается настройка, вроде бы всё работает, а при гигабитном линке раз и сломается.
Может быть имеет смысл, поиграть настройкой длины окна?

[alx]

Replying to san:

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

??? Верно ли я тебя понял, что пользователи спрашивали именно об ingress ограничении скорости?

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

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

я планировал протестировать эту настройки и описать в РЭ.

Ты потестировал. :) А описывать в РЭ, насколько я помню, мы договорились только настройки, имеющиеся в краткой версии интерфейса. В краткой версии настроек ограничений скоростей нет.

Предлагаю оставить как есть. (с) :) А какие еще у нас могут быть варианты? Убрать чекбокс "Limit known unicast"?

Может быть имеет смысл, поиграть настройкой длины окна?

Я пробовал менять размер окна, никаких изменений в работе не было.

[san]

пользователи спрашивали именно об ingress ограничении скорости?

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

В краткой версии настроек ограничений скоростей нет.

Мой коварный план был добавить обе настройки ограничения в краткую версию.

... egress ограничение скорости ... у нас есть давным-давно.

Да, я подсказывал пользователям как её настроить через расширенную версию настроек, но добавлять в краткую версию кнопку настроек порта ради единственной настройки мне было неинтересно, а вот когда вторая настройка появилось, стало интересно)

Я пробовал менять размер окна, никаких изменений в работе не было.

Ясно.

Убрать чекбокс "Limit known unicast"?

Наверное разумнее оставить как есть.

Видимо таки придётся как-то адаптировать настройку ограничения с помощью счётчиков для краткой версии настроек Ethernet, но это значительно сложнее чем просто перенести пару полей ввода...

[san]

На самом деле интереснее было бы настройку egress иметь в плате GE-04/12, т.к. чаще её используют для подключения пользователей. Потенциально в её коммутаторе тоже есть возможность ограничения входящего трафика, но почему-то эта функция тоже не заработала корректно, при разработки платы и про неё забыли. Буду ковырять коммутатор GE, а с этим багом смирюсь :-)

[alx]

Replying to san:

На самом деле интереснее было бы настройку egress иметь в плате GE-04/12, т.к. чаще её используют для подключения пользователей.

??? А разве настройка "Rate limit [Egress]", которая есть, по-моему, с самого рождения - не оно? Она есть для всех портов, включая кроссовый...

[san]

Так это Egress, а я про Ingress.
Если к портам платы подключены два пользователя, то ограничить скорость каждого в отдельности на входе не выйдет, только если каждому пользователю по отдельной плате GE выдать, но это затратно.

[alx]

Replying to san:

Так это Egress, а я про Ingress.

Тогда ты, очевидно, оговорился, потому что ты написал: "интереснее было бы настройку egress иметь..." :)

[san]

точно)

[alx]

Replying to san:

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

??? Не понимаю...

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

Во-вторых, как оно может гарантировать, что будет не более? Допустим, трафик приходит в порт 1 и уходит в канал, подключенный к порту 2. Мы хотим, чтобы в канал уходило не более 1 Мбит/с. Мы настроили ограничение ingress трафика порта 1 в 1 Мбит/с. Замечательно, задача решена... Но потом вдруг пришел трафик в порт 3, который коммутатор тоже отфорвардил в порт 2, в результате в канал уже ушло больше чем 1 Мбит/с! Нет, не гарантирует ingress limit что куда бы то ни было уйдет не больше требуемого. Или ты предполагал на всех десяти портах установить ingress limit 0.1 Мбит/с чтобы даже после сложения их всех получилось не более 1 Мюит/с? :)

Зато egress limit - гарантирует, так как трафик ограничивается уже после выходной очереди порта, и никакого "дополнительного" трафика там появиться уже не может...

Да, такую схему можно настроить с помошью шейпинга (у нас даже инструкция/пример ​есть), но сама настройка будет сложнее.

Да, можно и так тоже.

Я пробовал менять размер окна, никаких изменений в работе не было.

Ясно.

Я тебе больше скажу, именно в гигабитном режиме окно 10 мс - это значение по умолчанию. :)

Наверное разумнее оставить как есть.

Я сейчас вспомнил, что работа/нерабоза также зависит от величины ограничения. То есть нельзя сказать, что в гигабитном режиме оно не работает вообще совсем. :) Это еще один аргумент за оставить как есть. :)

[alx]

Replying to san:

...бывает и удобнее и нагляднее сразу на приёме пользовательского трафика в наш порт

Забыл этот момент упомянуть. Чем ограничение ingress удобнее и нагляднее ограничения egress мне тоже непонятно... :)

[san]

Чем ограничение ingress удобнее и нагляднее ограничения egress

я имел в виду что ingress удобнее чем настройка шейпинга

??? Не понимаю...

Пример: пользователь1 подключен к порту 8, а пользователь2 к порту 9, а "канал" это плата SM-02 на порту 2.
Канал шириной 3 Мбита, предполагается, что каждому пользователю дано по 1 Мбит/с в этом канале.
Если пользователь1 начнёт генерить 5мбит трафика, то займёт весь канал и пакеты пользователя2 будут теряться. хоть он и передаёт в рамках дозволенной ширины. Если настроить ingress ограничение для портов пользователей, то они не смогут отправлять в канал трафик больше чем задано ограничением.

[alx]

Replying to san:

Пример: пользователь1 подключен к порту 8, а пользователь2 к порту 9, а "канал" это плата SM-02 на порту 2.
Канал шириной 3 Мбита, предполагается, что каждому пользователю дано по 1 Мбит/с в этом канале.

Это задача ровно из так называемого "семинара". И решается она так, как по приведенной ранее тобой ссылке.

Если пользователь1 начнёт генерить 5мбит трафика, то займёт весь канал и пакеты пользователя2 будут теряться. хоть он и передаёт в рамках дозволенной ширины. Если настроить ingress ограничение для портов пользователей, то они не смогут отправлять в канал трафик больше чем задано ограничением.

А это - неправильное решение задачи. Точнее, это решение видоизмененной задачи.

Представь себе, что пользователь 1 начинает передавать трафик пользователю 2. И тут он с удивлением обнаруживает, что не может передавать со скоростью больше чем 1 Мбит/с несмотря на то что трафик локальный и не занимает канал, и оба подключены гигабитными линками. Обидно, правда? :) Но это еще что, сейчас станет еще обиднее. Предположим, что пользователь 1 передает пользователю 2 трафик со скоростью 0.8 Мбит/с. А теперь он дополнительно к этому трафику хочет передать что-то удаленному пользователю через канал. И обнаруживает, что несмотря на разрешенные 1 Мбит/с не может нагрузить канал более чем на 0.2 Мбит/с!!! :(

То есть да, подходя формально, поставленная задача решена, но плохим, негодным способом.

[san]

Я пробовал менять размер окна, никаких изменений в работе не было

1. Алексей, мы с Сашей немного помучили свитч и случайно выяснилось, что если в биты 26..21 регистра 0x02040140 задающие размер окна для линка 1Gb/s установить старший бит(26) =1, то проявляется эта странность, а если старший бит 0, то ограничение скорости работает и не "ломается".

2.Ещё мы заметили сноску в описании регистра 0x02040140 (стр.624), в которой сказано, что шаг размера окна линейно зависит от "Core Clock", а в даташите указано значение шага(250us) для Core Clock=200MHz. Скажи пожалуйста, какое значение Core Clock в нашем случае?

[alx]

Replying to san:

Я пробовал менять размер окна, никаких изменений в работе не было

1. Алексей, мы с Сашей немного помучили свитч и случайно выяснилось, что если в биты 26..21 регистра 0x02040140 задающие размер окна для линка 1Gb/s установить старший бит(26) =1, то проявляется эта странность, а если старший бит 0, то ограничение скорости работает и не "ломается".

Интересно... Значит, можно установить значение 0x1f (и пропорционально уменьшить окна для других скоростей) - и все будет работать... Вероятно, в моих экспериментах я окно сильно уменьшать не пробовал...

2.Ещё мы заметили сноску в описании регистра 0x02040140 (стр.624), в которой сказано, что шаг размера окна линейно зависит от "Core Clock", а в даташите указано значение шага(250us) для Core Clock=200MHz. Скажи пожалуйста, какое значение Core Clock в нашем случае?

К сожалению, в документации об этом ничего не говорится. Однако говорится, что есть выход LEDCLK (вывод 111), на котором присутствует частота core clock, деленная на 128. Можно посмотреть осциллоскопом, какая там частота, и умножить на 128.

[san]

Интересно... Значит, можно установить значение 0x1f (и пропорционально уменьшить окна для других скоростей) - и все будет работать... Вероятно, в моих экспериментах я окно сильно уменьшать не пробовал...

Да, Саша тестил продолжительное время с окном 0x1f, всё работало.

К сожалению, в документации об этом ничего не говорится. Однако говорится, что есть выход LEDCLK (вывод 111), на котором присутствует частота core clock, деленная на 128. Можно посмотреть осциллоскопом, какая там частота, и умножить на 128.

Саша намерял там 1.123 MHz.
И ещё оказывается у нас есть Hardware Specifications, там написано что настройки PLL защёлкиваются при старте в регистр 0x00000004 в параметр PLLConfigInit в зависимости от напряжения на ногах: LEDCLK,LEDSTB,LEDDATA. В нашем случае ножки висят в воздухе, и документ говорит что параметр PLLConfigInit должен быть равен 0x4, что соответствует Core Clock == 178MHz, однако в реальности PLLConfigInit у нас читается как ноль, что соответствует Core Clock == 140MHz.

[san]

Подниму тикет, т.к. какое-то продвижение есть.

1. Выше уже замечено, что с окном 0x1f ограничение как-то работает и баг не проявляется
2. Замечены некоторые странности. Саша П. довольно долго мучил свитч и выяснил что при любых настройках окон, значение лимита записанное в регистр 0x0200xx10 применяется с шагом 24 единицы(т.е. если записывать в регистр любые значения от 0 до 23, то реальное ограничение неизменно равно лимит1, если записывать значения от 24 до 47, то ограничение равно лимит2 и так далее.). Однако оказалось, что этот "магический шаг" зависит от размера пакета которым Саша тестирует пропускную способность :).
   • При размере пакета в 1500 байт "магический шаг" = 24.
   • При размере пакета в 1000 байт "магический шаг" = 16.
   • При размере пакета в 500 байт "магический шаг" = 8.

3. Расчётные настройки не соответствуют установленному ограничению, например для нашей частоты ядра(143.7МГц.) шаг установки окна будет 184us и окно 0x1f будет соответствовать 5888us. Значит шаг лимита будет k= (64*8)/5.888=86.95 кбит/с. Пробуем установить скорость 50 000 кбит/s -> R[0x0200xx10]=(50 000/86.95) = 575. Записываем в регистр значение и видим, что скорость ограничена примерно на уровне 20 000 ... 25 000 кбит/с

[alx]

Replying to san:

3. Расчётные настройки не соответствуют установленному ограничению,

Может расчет неверный? :)

например для нашей частоты ядра(143.7МГц.) шаг установки окна будет 184us

Почему 184? Согласно документации, при core clock 200 МГц шаг равен 256 us. Там же сказано, что шаг линейно изменяется пропорционально core clock. Логика подсказывает, что при снижении core clock окно увеличивается. Следовательно, логично предположить, что при core clock 143.7 МГц шаг составит (256 * 200 / 143.7) = 356 us.

и окно 0x1f будет соответствовать 5888us.

(356 * 32) = 11.4 ms

Значит шаг лимита будет k= (64*8)/5.888=86.95 кбит/с.

k = (64 * 8) / 11.4 = 45 кбит/с

Пробуем установить скорость 50 000 кбит/s -> R[0x0200xx10]=(50 000/86.95) = 575. Записываем в регистр значение и видим, что скорость ограничена примерно на уровне 20 000 ... 25 000 кбит/с

(45 * 575) = 25875 Чертовщина какая-то! :)

[san]

Почему 184? Согласно документации, при core clock 200 МГц шаг равен 256 us. Там же сказано, что шаг линейно изменяется пропорционально core clock.

Ну раз сказано пропорционально и считали пропорционально :)

Логика подсказывает

Логика это хорошо, спасибо.
k = (64 * 8) / 11.4 = 45 кбит/с
50 000 -> 1111, видим 46 000 ...47 000
Ну более-менее близко, наверное можно будет оставить так.

[alx]

Replying to san:

Ну раз сказано пропорционально и считали пропорционально :)

Я думаю, мне на месте авторов тоже вряд ли пришло бы в голову, что кому-то потребуется уточнение, прямо или обратно пропорционально... :)

[san]

Replying to san:

1. Выше уже замечено, что с окном 0x1f ограничение как-то работает и баг не проявляется

Внезапно нашелся документ Errata на этот коммутатор, там так и сказано, что при значениях больше 31 в битах [26..21] лимит корректно не работает и в качестве воркэраунда советуют не записывать значение больше :)

[alx]

In 2012/sw:

В функции ingress limit портов ethernet платы SW-01 изменено временное окно
замера скорости, благодаря этому ограничение работает и для режима 1 Гбит/с
(раньше не работало). В веб-интерфейсе значение ограничения пересчитывается
в соответствии с новым значением окна. Closes #461.