уменьшается скорость по TCP через свичи Опции

[RoadRunner]

Всем доброго времени суток.
Если коротко, проблема в том, что при пропускании TCP трафика через цепочку 100-мегабитных свичей сильно падает скорость, примерно 7 Мбит на свич. Предполагаю, что дело в стандартной задержке свича, т.е. при двунаправленном трафике, типа запрос-ответ скорость естественно будет падать. Исходя из этого попытался увеличить MSS (максимальный размер сегмента), ожидая что кол-во подтверждений уменьшится, но Windows эту опцию увеличивать не дает, от чего закрались сомнения, а решит ли это проблему? Другой возможный вариант - переход на UDP и соответственно организация протокола обмена самому. Больше ничего в голову не приходит.

Т.е. вопрос: можно как-то оптимизировать TCP чтобы скорость хотя бы не так быстро падала при увеличении кол-ва свичей? Имеет ли смысл на UDP переходить?
Буду очень благодарен за помощь

Сообщение отредактировал RoadRunner - Feb 15 2012, 11:35

[RoadRunner]

А какую реализацию TCP используете?

LwIP на передающей стороне (процессор Blackfin), на приемной обычная windows 7. Точнее так предполагается делать в конечном варианте, а пока экспериментировал на двух ПК с windows 7.
Вообще странно, что увеличение размера приемного окна не помогло, по идее этого достаточно должно быть чтобы передающий пачками сегменты гнал.. Если только размер этого самого congestion window никак не вмешивается..

[VslavX]

LwIP на передающей стороне (процессор Blackfin), на приемной обычная windows 7. Точнее так предполагается делать в конечном варианте, а пока экспериментировал на двух ПК с windows 7.
Вообще странно, что увеличение размера приемного окна не помогло, по идее этого достаточно должно быть чтобы передающий пачками сегменты гнал.. Если только размер этого самого congestion window никак не вмешивается..

А Вы TCP опции RFC-1323 для Windows разрешили? ЕМНИП даже для 7-ки надо что-то в реестре патчить. Иначе приемное окно не будет масштабироваться и его размер не превысит 64Кбайт. Вроде бы Congestion Window никак вмешиваться не должен, если нет потерь пакетов.