Я пытаюсь улучшить пропускную способность TCP в «сети с высокой задержкой», с некоторыми отбрасыванием пакетов между машинами Linux.
Я установил tcp_mem
, tcp_wmem
и tcp_rmem
на «8192 20530752 20530752».
Я установил rmem_max
, wmem_max
, rmem_default
и wmem_default
на «20530752».
Я установил netdev_max_backlog
и txqueuelen
до 50000.
Я установил tcp_congestion_control
до «масштабируемого».
Я использую nist (cnistnet) для моделирования задержки в 50 мс (25 мс для каждого направления) и падения на 0,5% (0,25% для каждого направления), а получаемая полоса пропускания составляет около 7,48 Мбит / с.
Вот таблица результатов (с использованием iperf для измерения ставок):
| 0ms | 50ms
0% | 710mbps | 276mbps
0.5% | 181mbps | 7.48mbps
Я не ожидал, что задержка так сильно повлияет на пропускную способность (только не с этими большими окнами TCP). Я тоже не ожидал, что капли будут иметь такой эффект. Особенно с «масштабируемым» алгоритмом, поскольку предполагается, что «окно перегрузки» очень быстро восстанавливается после отбрасывания пакетов.
я использовал tcpdump
& sar
(часть sysstat), чтобы попытаться увидеть, что происходит. В отчетах sar я не обнаружил ничего подозрительного. И в дампе tcp вижу:
«Rexmt data pkts» = 88 (из 8183 отправленных)
«Байты данных rexmt» = 127 424 байта (из отправленных 44 649 104 байтов)
«Avg owin» = 135 964 байта.
«Среднее время возврата» = 53,5 мс.
Это лучшее, что может сделать TCP? Нет ли другого алгоритма, который может обеспечить лучшую пропускную способность в этом сценарии? Является ли мой сценарий необычным (я думаю, что задержка в 50 мс с падением на 0,5 - это нормальные свойства WAN)?