Jump to content

    

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

Всем доброго времени суток.

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

 

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

Буду очень благодарен за помощь

Edited by RoadRunner

Share this post


Link to post
Share on other sites
Т.е. вопрос: можно как-то оптимизировать TCP чтобы скорость хотя бы не так быстро падала при увеличении кол-ва свичей? Имеет ли смысл на UDP переходить?

Буду очень благодарен за помощь

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

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

 

Share this post


Link to post
Share on other sites
А какую реализацию TCP используете?

 

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

Вообще странно, что увеличение размера приемного окна не помогло, по идее этого достаточно должно быть чтобы передающий пачками сегменты гнал.. Если только размер этого самого congestion window никак не вмешивается..

Share this post


Link to post
Share on other sites
LwIP на передающей стороне (процессор Blackfin), на приемной обычная windows 7. Точнее так предполагается делать в конечном варианте, а пока экспериментировал на двух ПК с windows 7.

Вообще странно, что увеличение размера приемного окна не помогло, по идее этого достаточно должно быть чтобы передающий пачками сегменты гнал.. Если только размер этого самого congestion window никак не вмешивается..

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

 

Share this post


Link to post
Share on other sites
А Вы TCP опции RFC-1323 для Windows разрешили? ЕМНИП даже для 7-ки надо что-то в реестре патчить.

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

 

Глобальные параметры TCP

------------------------------------------------------

Состояние масштабирования на стороне приема : enabled

Состояние разгрузки канала : automatic

Состояние NetDMA : enabled

Прямой доступ к кэшу (DCA) : disabled

Уровень автонастройки окна получения : normal

Поставщик надстройки контроля перегрузки : none

Мощность ECN : disabled

Отметки времени RFC 1323 : disabled

 

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

Хотел изменить TcpAckFrequency, что бы подтверждения пореже генерить, так этой настройки на семерке нету. Пробовал в ручную создать - создается, но не работает, как слал одно подтверждение на два пакета, так и шлет. В XP попроще было)

Edited by RoadRunner

Share this post


Link to post
Share on other sites
С этим у меня на семерке сложности.. В настройках у меня то, что по умолчанию, т.е.

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

 

Share this post


Link to post
Share on other sites
А Вы WireShark-ом прихватите траффик и посмотрите что там в сегменте SYN посылается - есть ли там опция масштабирования окна или нет.

 

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

Edited by RoadRunner

Share this post


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

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

 

Share this post


Link to post
Share on other sites

В общем разобрался кажется.

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

 

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

Share this post


Link to post
Share on other sites
...попытался увеличить MSS (максимальный размер сегмента)...

 

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

 

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

 

 

удачи вам

(круглый)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this