если внимательно почитать пдф по ссылке, то там описана способность обработать 2 конкретными микросхемами мелкие кадры
а вот цифры тестирования моего железа:

результы другого тестера по RFC 2544


при уменьшении MTU уменьшается скорость передачи полезной информации за счет роста процента служебных заголовочных байтов. А сама загрузка Ethernet-канала падает только на слабом железе, неспособном обработать много пакетов.

если внимательно почитать тот пдф, то видно, что снижение скорости передачи полезных данных связано с наличием заголовков Eth/IP/TCP и при передаче маленьких пакетов, размер этого заголовка может существенно превышать размер передаваемых в этом пакете полезных данных.
Это собс-но свойство самого стека протоколов Ethernet, а не каких-то там конкретных микросхем GbE контроллеров. Ну и в результатах тестирования Вашего железа хорошо бы выделить скорость передачи полезных данных от скорости передачи пакетов содержащих, кроме данных сетевые заголовки и прочие FCS.

топикстартер стремится к ограничению передачи полезной информации или всетаки к ограничению полосы пропускания шины?

ТС стремится согласовать ёмкости каналов оптимальным образом, а именно, ограничить ёмкость одного из каналов.
Ограничение емкости путём потери пакетов слишком сильно зависит от слишком многих факторов и может приводить к излишним потерям в целом. Что говорится, как срастётся, так срастётся. В общем случае, flow control должен работать существенно лучше потери пакетов. Ещё лучше должно работать ограничение емкости канала на уровне источника пакетов, подключённого к быстрому каналу. Для более сложых задач можно громко задуматься о QoS, и т.д.


Если есть комутатор и он не устраивает, лучше найти подходящий. Например, для 88E6096 можно задать Egress Sharping c точностью 10Mbps для диапазона 100...1000Mbps.

Исползуется коммутатор 88Е6122. Заменить его уже нельзя, ибо железо сделано, и на переделку нет не времени не средств.

PORT 3 переведите в режим MII и установите МАС mode и подавайте с ПЛИС на них нужную частоту F и у вас на этом порту будет скорость 4*F.
А далее цепляйте на этот порт микросхему PHY и вы получите ограниченный по пропускной способности 10/100 BASE-T.

Для 200Мбит и выше, что ли? А для GMII номер не прокатит.
Придётся ТС flow control на плисине ваять. Но до этого разобраться с магической цифрой 200Мбит не мешало бы. Да и по всей цепочке пройтись. М.б. достаточно где-нибудь что-то типа таймаута подкруть.

П.С. Да и со стандартным PHY на этом же порту номер не пройдёт.
"Ограниченный по пропускной способности 10/100 BASE-T" будет уже никакой не 10/100 BASE-T.

Для GMII тож должно прокатить, но я не пробовал.
Flow control уже сваяно в 88Е6122, зачем в ПЛИС то?

10/100 BASE-T стандарт будет соблюден, так как микросхема PHY будет тактироваться кварцем 25 Мгц! и скорость будет 100 мбит, а скорость передачи полезных данных (полоса) будет 40мбит если MII тактировать частотой 10 Мгц, ну или 50 кбит если 50 Кгц. Это я в железе проверял 100%. На коммутаторе DLINK или другом, не важно, определялся интерфейс 100мбит!

Сообщение отредактировал vadimp61 - Jun 18 2014, 13:46

- Для GMII клоки обычно генерятся в недрах девайсов, со стороны передатчиков шины, и завести их со стороны не удастся. Во всяком случае, мне подходящие девайсы не попадались.
- Flow control должны "понимать" оба устройства, а управление трафиком в данном случае должно идти от плисины, т.к. переполнение буфера будет именно там.
- Клоки на MII идут от PHY. Как раз те самые 25 МГц идут на выход клока передачи. Клок приема обычно извлекается из принимаемого сигнала, но могут быть вариации с использованием клока на входе кварцевого генератора, т.е. тех же 25 МГц .
И как мы будем тактировать MII? Если взять клоки для MAC со стороны, в части данных наступит полный трындец.
Уж не скажу, что Вы и как проверяли в железе, но 10/100 PHY к MII Вы никогда самостоятельно не полключали, это точно.

Номер с клоком может прокатить, если по MII подключаются друг на друга два MAC. И то, если этот режим в приципе предусмотрен для конкретных девайсов.
На таком линке ни о каких 10/100 BASE-T не может быть речи по-умолчанию. Какой именно интерфейс определяется в коммутаторе, значения не имеет.

П.С. И мы уже вроде бы выяснили, что MII к задаче ТС не имеет никакого отношения? 200Мбит и более, однако.

- GTX_CLK на 88E1111 вход, а ТХ_CLK (MII) выход и это разные ноги. RX_CLK всегда выход и она одна для обеих шин.
- согласен она, ПЛИС, должна формировать CLK и TEN причем CLK лежит в пределах DC...25МГЦ
- если брать чисто подключение PHY к MII то да тут только 25 Мгц от PHY к MII. Напрямую PHY к MII не подключал тут Вы правы. Я использовал
коммутатор 88Е6060 со встроенными PHY и его MII через ПЛИС подключали к TDM шине с разной полосой пропускания от 16 кбит до 15 Мбит.
HDLC протокол реализовывали в ПЛИС. В случае ADM6993 в которую встроен HDLC протокол и шиной SNI все вообще очень просто получалось.
ЗЫ. ну раз 200 мбит то там только GMII или RGMI или TBI.

ЗЫ.ЗЫ А не, вспомнил 12 лет назад было RTL8201-ПЛИС, но на 10 мбит все работало по MII шине. На 100 мбит не запускали
и LXT907 - ПЛИС по SNI

Сообщение отредактировал vadimp61 - Jun 18 2014, 19:29

Похоже то ограничение скорости, которое получается связано с задержкой пакетов в среде. Пинг проходит где-то за 2 мс

- Не путайте разные режимы работы девайсов. Впрочем, не Вы первый. Свистопляска с клоками при переходе с MII на GMII и обратно происходит у меня почти на каждом проекте. Заказчик решает изменить тип девайса в последний момент, бойцы быстро прикручивают новую физику, и после этого в 50% случаев появляются косяки с клоками. Так вот, когда речь идёт о GMII, клоки данных идут с той же стороны, откуда идут данные.

- Что и требовалось доказать. Только мак на мак. И именно на MII из-за подходящей структуры тактирования.
Но приём действительно полезный, хотя к сабжу неприменим. Когда надо, сразу и не вспомнишь.
Спасибо, что напомнили и пояснили конкретику вашего случая.



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

ТС,
можете чуть подробнее по задаче, пока что-то задача выглядит туманно.
Сколько у вашего устройства входных портов Ethernet? Какова их максимальная пропускная способность?

Если я правильно понял, то схема ваша выглядит так:



Если так, то вам достаточно сделать отбрасывание пакетов. Все порты коммутатор будет обслуживаться равноприоритетно и все будут иметь равный доступ к исходящему каналу. И ситуации когда один генерит 200, другой 100, а исходящий поток только 200, и пролезает только первый поток не будет.
В данной схеме будут передаваться данные от всех портов Eth.

Сообщение отредактировал insektazz - Jun 25 2014, 14:34

Схема, почти такая как вы нарисовали. Только портов ethernet 2, а реально для тестов используется 1.
Реализовали flow control. Результат тот-же. И виной всему задержка, т.к. когда ее исключаем, то получаем полную скорость.

Можно с этого момента подробнее?
Как тестируете? Что значит исключаем ее?