Я пытаюсь улучшить пропускную способность TCP через «сеть с высокой задержкой» между машинами Linux.
Я установил tcp_mem, tcp_wmem и tcp_rmem на «8192 7061504 7061504».
Я установил rmem_max, wmem_max, rmem_default и wmem_default на «7061504».
Я установил netdev_max_backlog и txqueuelen до 10000.
Я установил tcp_congestion_control до «масштабируемого».
Я использую «nist» (cnistnet) для моделирования задержки в 100 мс, и получаемая мной полоса пропускания составляет около 200 Мбит / с (без задержки я достигаю около 790 Мбит / с).
Я использую iperf для выполнения тестов и TCPTrace для анализа результатов, и вот что у меня получилось:
Со стороны ресивера:
max win adv: 5294720 байт
avg win adv: 5273959 байт
отправлено пакетов: 0
На стороне отправителя:
фактические байты данных: 3085179704
Байт данных rexmt: 9018144
max owin: 5294577 байт
в среднем owin: 3317125 байт
RTT мин: 19,2 мс
RTT макс: 218,2 мс
RTT в среднем: 98,0 мс
Почему я достигаю только 200 Мбит / с? Я подозреваю, что «owin» имеет к этому какое-то отношение, но я не уверен (эти результаты относятся к 2-минутному тесту. 1-минутный тест имел «среднее значение» 1552900)…
Я ошибаюсь, ожидая, что пропускная способность будет почти 790 Мбит / с, даже если задержка составляет 100 мс?
(Я пробовал использовать большие числа в конфигурациях окон, но это не помогло)
Это распространенная проблема TCP, которая называется «Длинная толстая трубка». Если вы погуглите эту фразу и TCP, вы найдете много информации об этой проблеме и возможных решениях.
Эта ветка содержит множество расчетов и предложений по настройке TCP-стека Linux для такого рода вещей.
Сайт
http://www.psc.edu/networking/projects/tcptune/
упоминает, что, поскольку в настоящее время Linux автоматически настраивает параметры TCP, изменение значений, вероятно, не улучшит ситуацию.
При этом, возможно, 100 мс вместе с большой пропускной способностью (не менее 790 Мбит / с) могут привести к огромному BDP, поэтому, возможно, автонастройка решит, что что-то не так и не заходит достаточно далеко ..
Попробуйте установить размер окна iperf так, чтобы оно действительно увеличивало произведение задержки полосы пропускания этой ссылки. Так средн. RTT * 1 Гбит / с должно дать вам примерно 10 МБ. Посмотрим, улучшит ли это положение вещей.
Единственный способ действительно начать понимать, что происходит, - это получить больше данных, иначе вы просто будете гадать или просить других людей угадать. Я рекомендую получить представление на уровне системы (ЦП, память, прерывания и т. Д.) С помощью sar из iostat пакет. Кроме того, вы должны получить дамп пакета с помощью Wireshark или tcpdump. Затем вы можете использовать Wireshark для анализа, поскольку у него есть много инструментов для этого. Вы можете построить график изменения размера окна, потери пакетов и т. Д.
Даже небольшая потеря пакетов в канале с высокой задержкой может немного снизить пропускную способность. Хотя моделируется - это немного странно. Множество маленьких пакетов также могут вызывать высокие прерывания (даже если они тоже могут быть смоделированы?).
Короче говоря, получите TCPDump и Sar, чтобы увидеть, что происходит на уровне пакетов и с вашими системными ресурсами.
Сколько памяти у этой машины? В tcp_mem настройки кажутся безумными, он настроил 28gb (7061504 * 4kb) для данных TCP глобально. (Но это не ваша проблема с перфомансом, поскольку вы, скорее всего, не достигнете этого предела при запуске теста с несколькими сокетами. Просто хотел упомянуть об этом, поскольку установка tcp_mem в значения tcp_xmem показывает очень распространенное ошибочное представление).
7 МБ, которые вы настроили по умолчанию, кажутся нормальными. Максимум, однако, может быть намного выше на больших трубах задержки. Для тестирования я бы использовал 64 МБ в качестве максимального числа для tcp_wmem и tcp_rmem, то вы можете исключить, что это ваш ограничивающий фактор. (Это приводит к раздутию ваших буферов, поэтому это работает только в том случае, если у вас ограниченный параллелизм, а соединение имеет низкий джиттер и разрывы).