Управление перегрузкой TCP для сетей с низкой задержкой 10GbE -> 1GbE?


11

У меня есть сервер с подключением 10GbE к коммутатору и 10 клиентов каждый с подключением 1GbE к одному коммутатору.

Параллельно запуская nuttcp на каждом из клиентов, я могу одновременно передавать 10 потоков данных TCP на сервер со скоростью, близкой к скорости соединения (т. Е. Всего лишь 100 мегабайт в секунду со всех 10 клиентов одновременно).

Однако, когда я меняю направление и отправляю данные с сервера клиентам - т. Е. 10 потоков TCP, по одному на каждого клиента, - происходит повторная передача TCP, и производительность падает до 30, 20 или даже 10 мегабайт в секунду. за клиента. Я хочу получить эти цифры, потому что эта модель трафика представляет определенные приложения, которые меня интересуют.

Я проверил, что мой сервер способен насыщать соединение 10GbE, выполнив тот же эксперимент через соединение 10GbE с аналогичным сервером. Я проверил, что нет ошибок на любом из моих портов.

Наконец, когда я принудительно ограничиваю (ограничиваю) размер окна TCP получателя, я могу получить пропускную способность несколько выше (30-40 мегабайт / сек); и если я зажимаю его крайне низко, я могу вернуть повторные передачи в ноль (с невероятно низкой пропускной способностью).

Таким образом, я достаточно уверен, что переполнил буферы в моем коммутаторе, что привело к потере пакетов из-за перегрузки. Тем не менее, я думал, что TCP контролирует перегрузку, должен был с этим справиться, со временем стабилизировавшись на уровне, превышающем 50% скорости передачи.

Итак, мой первый вопрос очень прост: какой алгоритм управления перегрузкой TCP лучше всего подходит для моей ситуации? Их доступно множество, но в основном они предназначены для сетей с потерями, высокоскоростных сетей с высокой пропускной способностью или беспроводных сетей ... Ничто из этого не относится к моей ситуации.

Второй вопрос: могу ли я попробовать еще что-нибудь?


1
Было бы полезно узнать, какая модель коммутатора. Различные коммутаторы обрабатывают очереди по-разному и помогут сузить решение.
scottm32768

2
Кроме того, разные коммутаторы имеют разный размер буфера, поэтому знание модели коммутатора поможет устранить проблемы с оборудованием из вашей проблемы.
cpt_fink

1
Кроме того, модели сетевых адаптеров, драйверы, версия Linux, ядро, дистрибутив и т. Д. Мои ответы на сетевой адаптер Myricom или Solarflare с Cisco 4900M будут отличаться от коммутатора Dell Powerconnect и сетевых адаптеров Intel.
ewwhite

Ответы:


2
  1. Вы хотели бы алгоритм, где размер окна не уменьшен резко, когда есть отбрасывание пакета. Это резкое падение размера окна, которое приводит к внезапному падению пропускной способности с трафиком TCP.

  2. Если ваш коммутатор и ваш сервер поддерживают управление потоком, попробуйте включить управление потоком. Насколько хорошо это работает, почти полностью зависит от кремния и прошивки коммутатора. По сути, коммутатор обнаружит выходную перегрузку на порте, который подключен к клиенту, определит, откуда поступили пакеты, и отправит кадры управления потоком из входного порта (т.е. обратно на сервер). Если сервер понимает кадры управления потоком, это уменьшит скорость передачи. Если все работает хорошо, вы получите оптимальную пропускную способность с практически нулевым отбрасыванием пакетов в выходном буфере коммутатора.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.