Мост 100 Мбит Ethernet <-> E2, Проблема с tcp/ip Опции

[xmir]

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

Разрабатываю устройство сопряжения 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 мбит при любом оконечном устройстве (компьютере) или это особенность моего устройства. Если второе, то подскажите как можно выправить ситуацию.

[krux]

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

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