Всем доброго времени суток. Есть такая задача. В устройство приходит 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

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

Влияет, просто Вы этого не видите..
А вот Intel (ap453) видит:
[attachment=85476:IntelAP453.jpg]