Всем доброго времени суток. Есть такая задача. В устройство приходит Ethernet поток 1 Гбит/с. Далее этот поток по другой среде передается в другое устройство. Максимальная пропускная способность среды ограничена. Как правильно убивать пакеты, когда их скорость превышает скорость передачи среды? Может кто-нибудь может поделиться алгоритмом прихлапывания?

..я может глупость скажу, но если соединение TCP/IP то повторная передача пакетов - проблема этого протокола, а если соединение по UDP то как пакеты не прибивай всё равно жалко и навсегда.
А резать пакеты можно как угодно - они , по идее, с точки зрения информационного содержимого равнозначны, кроме arp запросов.

Есть способ "противодавления". Это когда приемник сам начинает что-то передавать и забивает передатчик.. Потом передатчик после столкновения пакетов берет тайм-аут и снова пытается передавать...

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

По поводу простого прибивания, тоже вроде как так думали. Но получается такая картина: Если скорость среды до 200 мбит/с то вроде все гут. Если же она выше, то при работе одной задачи (например копирования), максимальная скорость оказывается 200 мбит/с. Но вот если запустить например два потока, то суммарная скорость соответствует скорости передачи среды. Вот такая вот фигня получается.

"Прихлапывать" вы хотите аппаратно на уровне управления микросхемой коммутатора или программно?

Если есть IP, то можно попробовать уменьшить MTU.
Если есть ICMP, то можно попробовать отправлять Source_quench.
Если есть TCP, то можно попробовать уменьшить Window size.

Наверное стоит использовать Ethernet flow control в частности Pause frame. Позволяет остановить передачу на заданное время.

тут уже прозвучало, что нужно стремиться управлять потоком а не только тупо терминировать.
Но строго по вопросу =
грохать можно без оглядки любые пакеты на IP уровне. Если что то теряется - проблемы верхних уровней, которые должны
выпрямлять ситуацию.

Убивать пакеты мы должны аппаратно в плисе, без разбора и определения типа протокола. Т.е. с микросхемы коммутатора в ПЛИС идет полный поток, а из него уже должен выходить ограниченный. Управлять коммутатором - не вариант, т.к. его возможности ограничения скорости трафика весьма ограничены. В частности максимальная скорость при ограничени по документации 225 Мбит/с.

Скорость среды: 200 мбит/с
Скорость 1 потока: 200 мбит/с
Суммарная скорость 2-х потоков по этой среде: 200 мбит/с

Какая фигня? Что вам не нравится?

Протокол TCP/IP имеет контрольные суммы и сам определяет достоверность пакетов.

Может быть это и проблемы верхних уровней. Но мы на них повлиять не можем. Наше устройство представляет собой прозрачный мост. С одной стороны подключили компьютер, с другой сеть (или другой комп). Все настройки на компе - стандартные. Заставлять пользователя их как-то менять - не самый лучший вариант. Я бы даже сказал - плохой вариант.



Не так. Скорость среды 300 Мбит/с. Суммарная скорость 2х потоков - 300. А вот если я использую только один поток - то 200. А 100 - пропали. Вот это и не нравится

Почитайте: http://ru.wikipedia.org/wiki/TCP/IP


А без вашего устройства 1 поток может дать больше 200 мбит?

убивал любые, не помещающиеся в буфер ПЛИС. все работает как часы, протоколы верхних уровней сами повторяют потерянные кадры. с flow control не заморачивался. MTU никак не влияет.

Ну так делайте как это делается например в DSL модемах у него с одной стороны сеть 100/1000 Mbit а с другой например Е1 со скоростью 2 мбит.
Делается так
Сеть 1 Г-PHY-GMII коммутатора - MII того же коммутатора тактируемая нужной частотой от ПЛИС - PHY- сеть 10/100 Mbit.
Если вам нужна скорость 40 Мbit даете тактовую на MII 10Мгц и пусть там коммутатор сам разбирается, но на выходе 10/100 у него будет не более 40 мбит.
Делали так много раз причем скорость на MII занижали до 50 Кгц - работало!
Проверено на ADM6993 и 88E6060.

С такой схемой вам хватит самого маленького МАХII

Влияет, просто Вы этого не видите..
А вот Intel (ap453) видит:
Нажмите для просмотра прикрепленного файла

если внимательно почитать пдф по ссылке, то там описана способность обработать 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мбит!

- Для 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

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

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

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



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

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

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



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

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

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