RoadRunner 0 15 февраля, 2012 Опубликовано 15 февраля, 2012 (изменено) · Жалоба Всем доброго времени суток. Если коротко, проблема в том, что при пропускании TCP трафика через цепочку 100-мегабитных свичей сильно падает скорость, примерно 7 Мбит на свич. Предполагаю, что дело в стандартной задержке свича, т.е. при двунаправленном трафике, типа запрос-ответ скорость естественно будет падать. Исходя из этого попытался увеличить MSS (максимальный размер сегмента), ожидая что кол-во подтверждений уменьшится, но Windows эту опцию увеличивать не дает, от чего закрались сомнения, а решит ли это проблему? Другой возможный вариант - переход на UDP и соответственно организация протокола обмена самому. Больше ничего в голову не приходит. Т.е. вопрос: можно как-то оптимизировать TCP чтобы скорость хотя бы не так быстро падала при увеличении кол-ва свичей? Имеет ли смысл на UDP переходить? Буду очень благодарен за помощь Изменено 15 февраля, 2012 пользователем RoadRunner Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 15 февраля, 2012 Опубликовано 15 февраля, 2012 · Жалоба Т.е. вопрос: можно как-то оптимизировать TCP чтобы скорость хотя бы не так быстро падала при увеличении кол-ва свичей? Имеет ли смысл на UDP переходить? Буду очень благодарен за помощь А какую реализацию TCP используете? На время полного оборота пакета (rtt - round-trip-time, AKA "пинг") скорее всего никак повлиять не получится. Но для случаев потоковой передачи сам TCP предусматривает "разгон" с использованием так называемого "окна контроля перегрузки" (congestion window) на передающей стороне. Но не все простые реализации TCP такое поддерживают. Из простых мер можно посоветовать увеличить размер приемного окна сокета TCP на принимающей стороне. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RoadRunner 0 15 февраля, 2012 Опубликовано 15 февраля, 2012 · Жалоба А какую реализацию TCP используете? LwIP на передающей стороне (процессор Blackfin), на приемной обычная windows 7. Точнее так предполагается делать в конечном варианте, а пока экспериментировал на двух ПК с windows 7. Вообще странно, что увеличение размера приемного окна не помогло, по идее этого достаточно должно быть чтобы передающий пачками сегменты гнал.. Если только размер этого самого congestion window никак не вмешивается.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 15 февраля, 2012 Опубликовано 15 февраля, 2012 · Жалоба LwIP на передающей стороне (процессор Blackfin), на приемной обычная windows 7. Точнее так предполагается делать в конечном варианте, а пока экспериментировал на двух ПК с windows 7. Вообще странно, что увеличение размера приемного окна не помогло, по идее этого достаточно должно быть чтобы передающий пачками сегменты гнал.. Если только размер этого самого congestion window никак не вмешивается.. А Вы TCP опции RFC-1323 для Windows разрешили? ЕМНИП даже для 7-ки надо что-то в реестре патчить. Иначе приемное окно не будет масштабироваться и его размер не превысит 64Кбайт. Вроде бы Congestion Window никак вмешиваться не должен, если нет потерь пакетов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RoadRunner 0 16 февраля, 2012 Опубликовано 16 февраля, 2012 (изменено) · Жалоба А Вы 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 попроще было) Изменено 16 февраля, 2012 пользователем RoadRunner Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 16 февраля, 2012 Опубликовано 16 февраля, 2012 · Жалоба С этим у меня на семерке сложности.. В настройках у меня то, что по умолчанию, т.е. А Вы WireShark-ом прихватите траффик и посмотрите что там в сегменте SYN посылается - есть ли там опция масштабирования окна или нет. Заодно посмотрите как там по времени пакеты следуют. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RoadRunner 0 16 февраля, 2012 Опубликовано 16 февраля, 2012 (изменено) · Жалоба А Вы WireShark-ом прихватите траффик и посмотрите что там в сегменте SYN посылается - есть ли там опция масштабирования окна или нет. Пишет Window scale: 8 (multiply by 256) - включена вроде. Не пойму как заставить его подтверждения слать скажем раз в 10 сегментов, пока шлет через два. Если бы удалось, все бы как на ладони было видно.. Изменено 16 февраля, 2012 пользователем RoadRunner Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SFx 0 16 февраля, 2012 Опубликовано 16 февраля, 2012 · Жалоба SACK опция должен быть, чтобы подтверждения были выборочными. http://opalsoft.net/qos/TCP-90.htm Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 16 февраля, 2012 Опубликовано 16 февраля, 2012 · Жалоба Пишет Window scale: 8 (multiply by 256) - включена вроде. Не пойму как заставить его подтверждения слать скажем раз в 10 сегментов, пока шлет через два. Если бы удалось, все бы как на ладони было видно.. ИМХО, тут не в подтверждениях дело. Если есть возможность и желание - выложите лог WireShark-а, может что интересное там получится разглядеть. Желательно два варианта - со свичом и без - чтобы разницу было видно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RoadRunner 0 20 февраля, 2012 Опубликовано 20 февраля, 2012 · Жалоба В общем разобрался кажется. Опция TCP в реестре TCPAckFrequency в windows 7 нормально работает, просто перезагрузиться забыл Только дело действительно не в ней было, а в количестве данных отправляемых за раз, т.е. в размере буфера данных передаваемых в функцию send. При уменьшении размера буфера ниже 32Кбайт каждый свич начинает отжирать от скорости, чем меньше объем блока, тем сильнее отжирает. На четырех свичах при размере блока 1Кбайт скорость у меня упала с 90Мбит до 54Мбит. Если свичи убрать скорость снова увеличивается до 90Мбит. При увеличении размера блока выше 64 Кбайт прироста в скорости не заметил (может потому что расти уже особо некуда ). Большое спасибо всем за помощь! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 21 февраля, 2012 Опубликовано 21 февраля, 2012 · Жалоба ...попытался увеличить MSS (максимальный размер сегмента)... по умолчанию 1500 во многих свитчах и у форточек. для понимания - снифти сегмент. с и без хостов подозреваемых в резке. форточки на отдачи режут по умолчанию. данный параметр связан с надёжностью канала(чем выше надёжность - тем больше по размерам можно загонять пакеты на IP уровне) и памятью на приёмной стороне. при сборке дефрагментированных пакетов на IP уровне так, же влияет время протухания принятых, но не собранных пакетов а так-же размер буфера. в инете как правило нет стэков TCP/IP с дефрагментацией на IP уровне (по крайней мере не было раньше), так что юзая готовый стэк - смотрите внимательней этот момент. да и ещё. вроде как максималка была 65535 байт IP пакета... удачи вам (круглый) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
