Здравствуйте.

Разрабатываю устройство сопряжения 100 Мбит/с Ethernet c последовательным интерфейсом 8448 кбит/с (физ. уровень E2, протокол самопальный). Проблема в том, что не удается выжать 8 Мбит/с на протоколе tcp/ip.
Устройство работает следующим образом: тетрады ethernet фрейма считываются ПЛИС из PHY микросхемы по MII и записываются во внутреннее ФИФО объемом 32 кбайт. По накоплению цельного фрейма в E2 выдается синхропоследовательность, а затем ethernet фрейм из ФИФО. При заполнении ФИФО выше определенного порога (например 30 кбайт), ethernet фреймы начинают отбрасываться. В обратную сторону аналогично - фреймы по E2 пишутся в ФИФО и по накоплению цельного фрейма выдаются в PHY. Ethernet фреймы ходят без ошибок (проверял анализатором BERcut-GE1). Пропускная способность канала на сырых ethernet кадрах 8 с копейками Мбит/с.
Проверяю передачу по tcp/ip следующим образом: соединяю 2 устройства по E2, ethernet порты подключаю к двум компьютерам и копирую файлы между ними под виндой. Смотрю загрузку сети в диспетчере задач. График загрузки сети дерганный, в среднем 4-5 %. При установке уровня отсечки ФИФО буфера 28 или 29 кбайт удалось добиться ровного графика загрузки сети на уровне 8% (8 Мбит/с) при копировании в одну из сторон (с ноутбука), но при копировании на ноутбук - дерганный график загрузки, в среднем 4-5 %. Пробовал еще уменьшать порог отсечки ФИФО постепенно до 24 кбайт, требуемого результата это не дало. Сетевая видеокамера загружает канал на требуемые 8% (но тут видимо UDP).
Вопрос собственно в чем: это проблема tcp/ip и невозможно добиться стабильной пропускной способности 8 мбит/с при передаче 100 мбит -> 8 мбит при любом оконечном устройстве (компьютере) или это особенность моего устройства. Если второе, то подскажите как можно выправить ситуацию.

По-хорошему, для Ethernet нужен flow control. Дропать пакеты при переполнении FIFO не есть гуд.
Вариантов несколько.
- Прикрутить самопальный flow control к имеющейся на ПЛИС схеме
- Поставить нормальный MAC, который это поддерживает
- Прикрутить вместо PHY какой-нибудь мелкий дешёвый свитчик (пара встроенных PHY и MII) и использовать его возможности.

Сделайте хотя бы 3-й пункт и все будет хорошо. Мы пользуем 88Е6060, правда на Е1. У нее внутри есть все что вы сейчас делали а матрице, останется добавить сериализатор и ESC последовательности.

Проблема в размере приемного окна TCP. крутится в windows в реестре, по умолчанию - 16 кбайт. На медленных каналах в большим временем задержки его надо бы уменьшать.
Ваш промежуточный буфер в 32к на FIFO делает только хуже, Приемная сторона видит отправку последовательной очереди из 32 кбайт, отправленных одним куском, считает что канал без потерь, и увеличивает окно, (при том что его надо бы уменьшить), а на следующей пачке передачи ждёт потерянные пакеты, посылая перезапросы только по истечении времени ожидания. читайте про bufferbloat.

Почему на стали делать GFP? Ведь он не слишком сложный, да ещё и через нефреймированный канал может работать.

проверять скорость методом копирования -не лучший способ, для это существуют специальные программы, считающие скорость на пакетах различной длины. А для точных измерений есть специальные анализаторы Ethernet,одним из них вы пользовались и получили:
.Вполне приличный результат.
вариант выправить ситуацию-установить у себя принудительно Ethernet на 10 Мбит. это позволит компу не накидывать кучу пакетов и потом переповторять передачу.
выведите наружу с плис сигнал "есть пакет из Ethernet, но нету места в ФИФО", он позволит лучше понимать процесс переполнения буфера.
Можно ограничивать более интелектуально -контролировать свободное место в ФИФО, смотреть длину пакета и отбрасывать его только если он не влезает. Например осталось место на 1400 байт, длинный пакет 1500 байт отбросить и можно набить кучу коротких пакетов по 64 байта.