Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Ограничение скорости Ethernet
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
Михаил_K
Всем доброго времени суток. Есть такая задача. В устройство приходит Ethernet поток 1 Гбит/с. Далее этот поток по другой среде передается в другое устройство. Максимальная пропускная способность среды ограничена. Как правильно убивать пакеты, когда их скорость превышает скорость передачи среды? Может кто-нибудь может поделиться алгоритмом прихлапывания?
Lmx2315
..я может глупость скажу, но если соединение TCP/IP то повторная передача пакетов - проблема этого протокола, а если соединение по UDP то как пакеты не прибивай всё равно жалко и навсегда.
А резать пакеты можно как угодно - они , по идее, с точки зрения информационного содержимого равнозначны, кроме arp запросов.
iosifk
Цитата(Михаил_K @ Jun 17 2014, 16:24) *
Всем доброго времени суток. Есть такая задача. В устройство приходит Ethernet поток 1 Гбит/с. Далее этот поток по другой среде передается в другое устройство. Максимальная пропускная способность среды ограничена. Как правильно убивать пакеты, когда их скорость превышает скорость передачи среды? Может кто-нибудь может поделиться алгоритмом прихлапывания?

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

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

По поводу простого прибивания, тоже вроде как так думали. Но получается такая картина: Если скорость среды до 200 мбит/с то вроде все гут. Если же она выше, то при работе одной задачи (например копирования), максимальная скорость оказывается 200 мбит/с. Но вот если запустить например два потока, то суммарная скорость соответствует скорости передачи среды. Вот такая вот фигня получается.
vadimp61
Цитата(Михаил_K @ Jun 17 2014, 16:24) *
Всем доброго времени суток. Есть такая задача. В устройство приходит Ethernet поток 1 Гбит/с. Далее этот поток по другой среде передается в другое устройство. Максимальная пропускная способность среды ограничена. Как правильно убивать пакеты, когда их скорость превышает скорость передачи среды? Может кто-нибудь может поделиться алгоритмом прихлапывания?

"Прихлапывать" вы хотите аппаратно на уровне управления микросхемой коммутатора или программно?
blackfin
Цитата(Михаил_K @ Jun 17 2014, 16:24) *
Максимальная пропускная способность среды ограничена. Как правильно убивать пакеты, когда их скорость превышает скорость передачи среды?

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

shurey
Наверное стоит использовать Ethernet flow control в частности Pause frame. Позволяет остановить передачу на заданное время.
kolobok0
Цитата(Михаил_K @ Jun 17 2014, 16:24) *
...Может кто-нибудь может поделиться алгоритмом прихлапывания?


тут уже прозвучало, что нужно стремиться управлять потоком а не только тупо терминировать.
Но строго по вопросу =
грохать можно без оглядки любые пакеты на IP уровне. Если что то теряется - проблемы верхних уровней, которые должны
выпрямлять ситуацию.
Михаил_K
Цитата(vadimp61 @ Jun 17 2014, 17:30) *
"Прихлапывать" вы хотите аппаратно на уровне управления микросхемой коммутатора или программно?


Убивать пакеты мы должны аппаратно в плисе, без разбора и определения типа протокола. Т.е. с микросхемы коммутатора в ПЛИС идет полный поток, а из него уже должен выходить ограниченный. Управлять коммутатором - не вариант, т.к. его возможности ограничения скорости трафика весьма ограничены. В частности максимальная скорость при ограничени по документации 225 Мбит/с.
Alien85
Цитата(Михаил_K @ Jun 17 2014, 18:43) *
Если скорость среды до 200 мбит/с то вроде все гут. Если же она выше, то при работе одной задачи (например копирования), максимальная скорость оказывается 200 мбит/с. Но вот если запустить например два потока, то суммарная скорость соответствует скорости передачи среды. Вот такая вот фигня получается.


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

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

Протокол TCP/IP имеет контрольные суммы и сам определяет достоверность пакетов.
Михаил_K
Цитата(kolobok0 @ Jun 17 2014, 23:45) *
грохать можно без оглядки любые пакеты на IP уровне. Если что то теряется - проблемы верхних уровней, которые должны
выпрямлять ситуацию.

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

Цитата(Alien85 @ Jun 18 2014, 10:11) *
Скорость среды: 200 мбит/с
Скорость 1 потока: 200 мбит/с
Суммарная скорость 2-х потоков по этой среде: 200 мбит/с

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

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


Не так. Скорость среды 300 Мбит/с. Суммарная скорость 2х потоков - 300. А вот если я использую только один поток - то 200. А 100 - пропали. Вот это и не нравится
Alien85
Почитайте: http://ru.wikipedia.org/wiki/TCP/IP

Цитата(Михаил_K @ Jun 18 2014, 12:13) *
Не так. Скорость среды 300 Мбит/с. Суммарная скорость 2х потоков - 300. А вот если я использую только один поток - то 200. А 100 - пропали. Вот это и не нравится

А без вашего устройства 1 поток может дать больше 200 мбит?
ZASADA
убивал любые, не помещающиеся в буфер ПЛИС. все работает как часы, протоколы верхних уровней сами повторяют потерянные кадры. с flow control не заморачивался. MTU никак не влияет.
vadimp61
Цитата(Михаил_K @ Jun 18 2014, 10:08) *
Убивать пакеты мы должны аппаратно в плисе, без разбора и определения типа протокола. Т.е. с микросхемы коммутатора в ПЛИС идет полный поток, а из него уже должен выходить ограниченный. Управлять коммутатором - не вариант, т.к. его возможности ограничения скорости трафика весьма ограничены. В частности максимальная скорость при ограничени по документации 225 Мбит/с.

Ну так делайте как это делается например в 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
blackfin
Цитата(ZASADA @ Jun 18 2014, 10:37) *
MTU никак не влияет.

Влияет, просто Вы этого не видите..
А вот Intel (ap453) видит:
Нажмите для просмотра прикрепленного файла
ZASADA
если внимательно почитать пдф по ссылке, то там описана способность обработать 2 конкретными микросхемами мелкие кадры
Цитата
This document discusses the "small packet" performance of Intel® 8255x and 8254x Ethernet controllers

а вот цифры тестирования моего железа:
Цитата
Throughput
Frame Rate,% Mb/s L2 Frm/s Status
64 100.00 761.905 1488095 Passed

результы другого тестера по RFC 2544
Цитата
Frame........Cfg.......Measured.....Measured.......Measured...........Pause
Length......Rate.........Rate.............Rate...............Rate.....Detected
(Bytes).....(Mbps).....(Mbps)...........(%)............(frms/sec)......................
64............1000.0.....1000.0........100.00..........1488045..............No


при уменьшении MTU уменьшается скорость передачи полезной информации за счет роста процента служебных заголовочных байтов. А сама загрузка Ethernet-канала падает только на слабом железе, неспособном обработать много пакетов.
blackfin
Цитата(ZASADA @ Jun 18 2014, 11:29) *
если внимательно почитать пдф по ссылке, то там описана способность обработать 2 конкретными микросхемами мелкие кадры

если внимательно почитать тот пдф, то видно, что снижение скорости передачи полезных данных связано с наличием заголовков Eth/IP/TCP и при передаче маленьких пакетов, размер этого заголовка может существенно превышать размер передаваемых в этом пакете полезных данных.
Это собс-но свойство самого стека протоколов Ethernet, а не каких-то там конкретных микросхем GbE контроллеров. Ну и в результатах тестирования Вашего железа хорошо бы выделить скорость передачи полезных данных от скорости передачи пакетов содержащих, кроме данных сетевые заголовки и прочие FCS.
ZASADA
топикстартер стремится к ограничению передачи полезной информации или всетаки к ограничению полосы пропускания шины?
prig
Цитата(ZASADA @ Jun 18 2014, 11:46) *
топикстартер стремится к ограничению передачи полезной информации или всетаки к ограничению полосы пропускания шины?

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

Цитата(Михаил_K @ Jun 18 2014, 10:08) *
... Управлять коммутатором - не вариант, т.к. его возможности ограничения скорости трафика весьма ограничены. В частности максимальная скорость при ограничени по документации 225 Мбит/с.

Если есть комутатор и он не устраивает, лучше найти подходящий. Например, для 88E6096 можно задать Egress Sharping c точностью 10Mbps для диапазона 100...1000Mbps.
Михаил_K
Цитата(prig @ Jun 18 2014, 13:14) *
Если есть комутатор и он не устраивает, лучше найти подходящий. Например, для 88E6096 можно задать Egress Sharping c точностью 10Mbps для диапазона 100...1000Mbps.

Исползуется коммутатор 88Е6122. Заменить его уже нельзя, ибо железо сделано, и на переделку нет не времени не средств.
vadimp61
Цитата(Михаил_K @ Jun 18 2014, 15:10) *
Исползуется коммутатор 88Е6122. Заменить его уже нельзя, ибо железо сделано, и на переделку нет не времени не средств.

PORT 3 переведите в режим MII и установите МАС mode и подавайте с ПЛИС на них нужную частоту F и у вас на этом порту будет скорость 4*F.
А далее цепляйте на этот порт микросхему PHY и вы получите ограниченный по пропускной способности 10/100 BASE-T.
prig
Цитата(vadimp61 @ Jun 18 2014, 16:13) *
PORT 3 переведите в режим MII...

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

П.С. Да и со стандартным PHY на этом же порту номер не пройдёт.
"Ограниченный по пропускной способности 10/100 BASE-T" будет уже никакой не 10/100 BASE-T.
vadimp61
Цитата(prig @ Jun 18 2014, 16:30) *
Для 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мбит!
prig
Цитата(vadimp61 @ Jun 18 2014, 17:42) *
Для 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Мбит и более, однако.
vadimp61
Цитата(prig @ Jun 18 2014, 20:34) *
- Для 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
Михаил_K
Похоже то ограничение скорости, которое получается связано с задержкой пакетов в среде. Пинг проходит где-то за 2 мс
prig
Цитата(vadimp61 @ Jun 18 2014, 23:18) *
- GTX_CLK на 88E1111 вход, а ТХ_CLK (MII) выход и это разные ноги. RX_CLK всегда выход и она одна для обеих шин.
...
- ...Я использовал коммутатор 88Е6060... и его MII через ПЛИС подключали к TDM шине с разной полосой пропускания от 16 кбит до 15 Мбит.
...


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

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


Цитата(Михаил_K @ Jun 19 2014, 12:12) *
Похоже то ограничение скорости, которое получается связано с задержкой пакетов в среде. Пинг проходит где-то за 2 мс

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

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

Код
Порт Eth 1 - |-------------------|
Порт Eth 2 - | м/с коммутатор    | - ПЛИС -
Порт Eth N - |-------------------|


Если так, то вам достаточно сделать отбрасывание пакетов. Все порты коммутатор будет обслуживаться равноприоритетно и все будут иметь равный доступ к исходящему каналу. И ситуации когда один генерит 200, другой 100, а исходящий поток только 200, и пролезает только первый поток не будет.
В данной схеме будут передаваться данные от всех портов Eth.
Михаил_K
Схема, почти такая как вы нарисовали. Только портов ethernet 2, а реально для тестов используется 1.
Реализовали flow control. Результат тот-же. И виной всему задержка, т.к. когда ее исключаем, то получаем полную скорость.
insektazz
Цитата(Михаил_K @ Jul 1 2014, 14:12) *
Схема, почти такая как вы нарисовали. Только портов ethernet 2, а реально для тестов используется 1.
Реализовали flow control. Результат тот-же. И виной всему задержка, т.к. когда ее исключаем, то получаем полную скорость.

Можно с этого момента подробнее?
Как тестируете? Что значит исключаем ее?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.