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

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

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

А какую реализацию TCP используете?
На время полного оборота пакета (rtt - round-trip-time, AKA "пинг") скорее всего никак повлиять не получится. Но для случаев потоковой передачи сам TCP предусматривает "разгон" с использованием так называемого "окна контроля перегрузки" (congestion window) на передающей стороне. Но не все простые реализации TCP такое поддерживают. Из простых мер можно посоветовать увеличить размер приемного окна сокета TCP на принимающей стороне.

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

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

С этим у меня на семерке сложности.. В настройках у меня то, что по умолчанию, т.е.

Глобальные параметры TCP
------------------------------------------------------
Состояние масштабирования на стороне приема : enabled
Состояние разгрузки канала : automatic
Состояние NetDMA : enabled
Прямой доступ к кэшу (DCA) : disabled
Уровень автонастройки окна получения : normal
Поставщик надстройки контроля перегрузки : none
Мощность ECN : disabled
Отметки времени RFC 1323 : disabled

По идее опция "Уровень автонастройки окна получения" это "Receive Window Auto-Tuning Level" т.е. как раз отвечает за увеличение окна выше 64К. Она включена. Остальные настройки, каюсь, не особо понимаю, что означают.
Хотел изменить TcpAckFrequency, что бы подтверждения пореже генерить, так этой настройки на семерке нету. Пробовал в ручную создать - создается, но не работает, как слал одно подтверждение на два пакета, так и шлет. В XP попроще было)

Сообщение отредактировал RoadRunner - Feb 16 2012, 06:24

А Вы WireShark-ом прихватите траффик и посмотрите что там в сегменте SYN посылается - есть ли там опция масштабирования окна или нет. Заодно посмотрите как там по времени пакеты следуют.

Пишет Window scale: 8 (multiply by 256) - включена вроде. Не пойму как заставить его подтверждения слать скажем раз в 10 сегментов, пока шлет через два. Если бы удалось, все бы как на ладони было видно..

Сообщение отредактировал RoadRunner - Feb 16 2012, 07:05

SACK опция должен быть, чтобы подтверждения были выборочными. http://opalsoft.net/qos/TCP-90.htm

ИМХО, тут не в подтверждениях дело. Если есть возможность и желание - выложите лог WireShark-а, может что интересное там получится разглядеть. Желательно два варианта - со свичом и без - чтобы разницу было видно.

В общем разобрался кажется.
Опция TCP в реестре TCPAckFrequency в windows 7 нормально работает, просто перезагрузиться забыл Только дело действительно не в ней было, а в количестве данных отправляемых за раз, т.е. в размере буфера данных передаваемых в функцию send. При уменьшении размера буфера ниже 32Кбайт каждый свич начинает отжирать от скорости, чем меньше объем блока, тем сильнее отжирает. На четырех свичах при размере блока 1Кбайт скорость у меня упала с 90Мбит до 54Мбит. Если свичи убрать скорость снова увеличивается до 90Мбит. При увеличении размера блока выше 64 Кбайт прироста в скорости не заметил (может потому что расти уже особо некуда ).

Большое спасибо всем за помощь!

по умолчанию 1500 во многих свитчах и у форточек. для понимания - снифти сегмент. с и без хостов подозреваемых в резке. форточки на отдачи режут по умолчанию. данный параметр связан с надёжностью канала(чем выше надёжность - тем больше по размерам можно загонять пакеты на IP уровне) и памятью на приёмной стороне. при сборке дефрагментированных пакетов на IP уровне так, же влияет время протухания принятых, но не собранных пакетов а так-же размер буфера. в инете как правило нет стэков TCP/IP с дефрагментацией на IP уровне (по крайней мере не было раньше), так что юзая готовый стэк - смотрите внимательней этот момент.

да и ещё. вроде как максималка была 65535 байт IP пакета...


удачи вам
(круглый)