Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Насчет последних параметров можнл поподробнее? Каков прирост в тестах?
Еще у меня есть одна проблема с Wifi. Я уже замучался. Имеем игру например L4D2 или Dota 2. Как только я присоединяюсь к сети с планшета у меня тут же повышаеься пинг на ноуте вплоть до потеря соединения. Ноут находится далеко, через 3 стены. Но iperf удавалось держать на 20 мбитах.
Также у меня в доме очень много Wifi точек. И как я понимаю, когда кто то на соседнем или на этом же канале начинает что то скачинать, у меня происходит такие же глюки сети.
Как вариант думал переходить на 5 ггц точку. Но мне пока что надо стабилизировать то что есть. Например уменьшить задержку уменьшив скорость или рутер перенастроить как нибудь. Нужно решение и под винду и под линукс.
Еще у меня есть одна проблема с Wifi. Я уже замучался. Имеем игру например L4D2 или Dota 2. Как только я присоединяюсь к сети с планшета у меня тут же повышаеься пинг на ноуте вплоть до потеря соединения. Ноут находится далеко, через 3 стены. Но iperf удавалось держать на 20 мбитах.
Также у меня в доме очень много Wifi точек. И как я понимаю, когда кто то на соседнем или на этом же канале начинает что то скачинать, у меня происходит такие же глюки сети.
Как вариант думал переходить на 5 ггц точку. Но мне пока что надо стабилизировать то что есть. Например уменьшить задержку уменьшив скорость или рутер перенастроить как нибудь. Нужно решение и под винду и под линукс.
Думаю, в вашем случае виноват вайфай. Дело в том, что чем дальше расположено одно из устройств, подключенных к сети, тем хуже работает вся сеть. В вашем случае, попробуйте сменить канал на 14, если ваши устройства поддерживают его, либо на 13, форсируйте 802.11n и выставите 802.11n Preamble в Green Field.
сеть 802.11n, а планшет — a/b/g?
гляньте сюда (http://habrahabr.ru/post/149447/) и оцените, что из этого применимо к вашей ситуации
гляньте сюда (http://habrahabr.ru/post/149447/) и оцените, что из этого применимо к вашей ситуации
О да, шикарная статья - золотой пантеон хабра. Там похоже до сих пор в комментариях общаются...
Если ее внимательно прочитать и позволит софт точки - можно настроить себе вайфай как боженька. Мой микротик после прочтения и вдумчивого кручения настроек зажил новой жизнью, хотя я думал уже его менять на что-то поновее.
Переход на 5GHz может помочь, но тут есть другая проблема — он хуже проходит через стены, и у вас может просто не пробить 3 стены до ноута.
Я как-то тестировал разные алгоритмы в условиях LFN (10Gb/s, 0.9ms ping, ёмкость сети 550кб), по ощущениям лучше всего себя показали Vegas и Illinosis, но разница там была на грани ощутимого. Меня интересовала в первую очередь latency от TCP, а не «выжимаемая скорость», причём в условиях недоутилизации канала.
В итоге по результатам сравнения я решил не заморачиваться и остаться на чём есть, ибо погрешность измерений была выше, чем разница между лучшими и средними.
В итоге по результатам сравнения я решил не заморачиваться и остаться на чём есть, ибо погрешность измерений была выше, чем разница между лучшими и средними.
Есть еще proprietary алгоритмы, такие как
en.wikipedia.org/wiki/FAST_TCP
en.wikipedia.org/wiki/Zeta-TCP
Тестировали оба. На long fat networks они значительно (+50%) обходят все остальные алгоритмы.
Разработчики говорят что они так-же хороши и для wifi / 3G.
en.wikipedia.org/wiki/FAST_TCP
en.wikipedia.org/wiki/Zeta-TCP
Тестировали оба. На long fat networks они значительно (+50%) обходят все остальные алгоритмы.
Разработчики говорят что они так-же хороши и для wifi / 3G.
Вы, случаем, не тестировали TCP-Fit vs YeAH vs FAST-TCP? Fit и Fast должны быть где-то рядом, а вот на каком уровне находится YeAH по сравнению с ними я, честно говоря, не нашел. Но FIT выглядит пушкой просто, судя по вот этому документу, он просто какое-то нереальное ускорение дает.
Настолько детально не сравнивали, и более того, про TCP-Fit я даже не слышал :)
Очень интересно проверить его в действии.
Еще очень интересное замечание касательно Zeta TCP. При его использовании значительно падает скорость на коротких линках с небольшой latency. Причем падает значительно, процентов на 25
Очень интересно проверить его в действии.
Еще очень интересное замечание касательно Zeta TCP. При его использовании значительно падает скорость на коротких линках с небольшой latency. Причем падает значительно, процентов на 25
Скажите, пожалуйста, Вы случайно не знаете, можно ли эти алгоритмы пощупать в живую и какой порядок цен на реализации?
Zeta вы можете протестировать совершенно без проблем, у них есть Free Trial:
download.appexnetworks.com
С Fast TCP немного сложнее. В конце прошлого года их купили Akamai. Осталось некоторое кол-во компаний, которые работают по старым договорам, но в целом тенденция к тому, что Fast TCP будет похоронен самим Акамаем.
По ценам все довольно гибко, можно торговаться. Из того что я знаю цены варьируются от одной, до нескольких сотен $ за лицензию.
download.appexnetworks.com
С Fast TCP немного сложнее. В конце прошлого года их купили Akamai. Осталось некоторое кол-во компаний, которые работают по старым договорам, но в целом тенденция к тому, что Fast TCP будет похоронен самим Акамаем.
По ценам все довольно гибко, можно торговаться. Из того что я знаю цены варьируются от одной, до нескольких сотен $ за лицензию.
А есть возможность как-то это оптимизировать на Windows? Я понимаю, что на Linux'e уйма вариантов, но всё же.
К сожалению, никак, наверное. В Windows есть выбор только между Compound и Reno.
Есть и не мало, примерно понять что можно подкрутить можно тут.
P.S.
Скрипт для более оптимальной настройки чем по умолчанию для 7, 2008, 2008R2 и более новых ОС (с некоторыми оговорками ибо часть параметров уже установлено в оптимальное положение. Для полной настройки на 8, 2012 и старше требуется powershell, там ещё есть профили настраиваемые и можно задать разные настройки для адаптеров локалки и инета, например, удобно в общем :) )
@echo off
echo Optimizing TCP/IP parameters...
if "%1" == "/RSS_supported_by_HW_and_configured" (
echo RSS supported by hardware and configured properly confirmed.
echo Enabling RSS...
netsh interface tcp set global rss=enabled
) else (
echo Setting RSS is default mode...
netsh interface tcp set global rss=default
)
echo Set compound TCP as CTCP...
echo Applicable only to Windows 7, Server 2008, Server 2008 R2.
echo On older versions, you get an error - ignore it,
echo there is a mechanism is not supported, and it does not change.
echo In newer versions, you also get an error, but they install
echo this parameter is not required and therefore will be ignored,
echo so that further action from you just does not required.
netsh interface tcp set global congestionprovider=ctcp
echo Enabling TCP Chimney Offload
netsh int tcp set global chimney=enabled
echo Set as default NetDMA...
netsh interface tcp set global netdma=default
echo Set as default DCA for NetDMA...
netsh interface tcp set global dca=default
echo Enabling ECN...
netsh interface tcp set global ecn=enabled
echo Enabling TCP Timestamps (RFC 1323)...
netsh interface tcp set global timestamps=enabled
echo Enabling TCP WSH...
netsh interface tcp set heuristics wsh=enabled
echo Optimizing TCP/IP parameters done.
пример его вызова с подтверждением работоспособности и поддержки RSS
@echo off
call install /RSS_supported_by_HW_and_configured
Где то есть ссылка для дополнительных настроек на W10?
Возможно, если честно — не искал. меня больше беспокоит что по заверениям MS они там выпиливают netsh в пользу PowerShell а разбираться в этом мне просто лень пока совсем не прижмёт.
P.S. я то администрированием занимаюсь от безысходности ибо нанять специалиста себе, буквально домой, просто средств нет.
P.S. я то администрированием занимаюсь от безысходности ибо нанять специалиста себе, буквально домой, просто средств нет.
Вопрос: в связке
Линукс-десктоп <= Ethernet => Роутер <= 3G => Интернет даст ли какой-нибудь эффект настройка TCP Congestion Control для обеспечения более «плавной» связи в Skype (иногда звук и картинка лагают) и где это нужно настраивать, на десктопе или на роутере?
Как бы на mac их поменять.
Имеет смысл менять алгоритм на Linux-серверах подключенных на 100Мбит/1Гбит? Если да, то на какой, YeAH?
Думаю да. В некоторых статьях рекомендуют htcp, но я не смог найти с ним адекватных сравнений, все уровня «Это обычный TCP, а это HTCP!»
Спасибо, надо будет почитать-потестировать.
Подскажите, а если есть http сервер, к которому связь через 3G, и алгоритмы TCP которого нельзя настраивать (условный ESP32), и клиент на Windows, в котором тоже не особо то что настроишь, то можно ли как-то улучшить связь в такой ситуации? Допустим поставить промежуточный прокси-сервер на Linux, в котором включить Hybla?
Думаю да. На канале 1GE разные алгоритмы по скорости передачи данных уже могут отличаться раза в 2-3.
Я сейчас использую алгоритм illinois, правда задачи у меня не совсем стандартные серверные.
У меня при последнем тестировании illinois и yeah давали результаты практически совпадающие в пределах погрешности, чуть хуже был westwood, остальные значительно хуже. Канал 1GE, используемый в тестах rtt min/avg/max/mdev = 5.511/5.520/5.553/0.048 ms.
Я сейчас использую алгоритм illinois, правда задачи у меня не совсем стандартные серверные.
У меня при последнем тестировании illinois и yeah давали результаты практически совпадающие в пределах погрешности, чуть хуже был westwood, остальные значительно хуже. Канал 1GE, используемый в тестах rtt min/avg/max/mdev = 5.511/5.520/5.553/0.048 ms.
Какие-то вещи в заголовке вообще к тсп и его поведению прямого отношения не имеют. Так если при загрузке канала пинг сильно увеличивается вместо появления потерь — значит провайдер шейпит. Но чаще полисит ака рэйт-лимит. Это проще и ближе к тому, какое ограничение накладывали бы физические параметры канала. При полисинге или ограничении физикой при загрузке канала под завязку кучей потоков потери для пинга будут неизбежны, тут как бы тсп ни при чем. Потери могут превращаться в увеличение задержки именно за счет провайдера.
На всяких там вайфай и 3ж все так плохо, потому что потери случайны, тсп трудно отличить случайные потери от потерь от перегрузки, отсюда такие фатальные проблемы. Для всевозможных беспроводных вещей придумали habrahabr.ru/post/155977/
На всяких там вайфай и 3ж все так плохо, потому что потери случайны, тсп трудно отличить случайные потери от потерь от перегрузки, отсюда такие фатальные проблемы. Для всевозможных беспроводных вещей придумали habrahabr.ru/post/155977/
ccfit.nsu.ru/~tregub/WirelessLectureNotes.pdf
с. 48
Влияние ошибок передачи на производительность TCP
…
В случае заполнения очередей пакетоожидающих отправки на маршрутизаторах, сужение congestion window — правильное действие, позволяющее уменьшить длину очередей. В случае потери пакетов по причинфизических сбоев в канале, эта мера лишь ухудшает ситуацию. Правильная реакция на потерю пакета в результате действия случайной помехи или коллизии — немедленная отправка новой копии пакета в надежде на то, что сбой передачи — возникший из-за постороннего всплеска электромагнитного излучения, экранирования передающей антенны, или попытки доступа со стороны другого передатчика — не повторится.
…
Итак, если за секунду теряется лишь 20 бит (каждый стотысячный, например), то механизмы TCP в результсдерживают нормальную доставку миллиона бит (каждого второго бита)!
с. 48
Влияние ошибок передачи на производительность TCP
…
В случае заполнения очередей пакетоожидающих отправки на маршрутизаторах, сужение congestion window — правильное действие, позволяющее уменьшить длину очередей. В случае потери пакетов по причинфизических сбоев в канале, эта мера лишь ухудшает ситуацию. Правильная реакция на потерю пакета в результате действия случайной помехи или коллизии — немедленная отправка новой копии пакета в надежде на то, что сбой передачи — возникший из-за постороннего всплеска электромагнитного излучения, экранирования передающей антенны, или попытки доступа со стороны другого передатчика — не повторится.
…
Итак, если за секунду теряется лишь 20 бит (каждый стотысячный, например), то механизмы TCP в результсдерживают нормальную доставку миллиона бит (каждого второго бита)!
Если есть следующая проблема — удалённый HTTP сервер имеет жётскую настройку таймаута (ну скажем 5 секунд).
При обращении к серверу в несколько потоков по ADSL, этот таймаут часто срабатывает.
Получается как будто есть два соединения к серверу, но Linux почему-то слишком долго посылает данные по одному из них,
при этом второе соединение простаивает эти 5 секунд и случается таймаут.
tcp_congestion_control=cubic
Я так понимаю это тоже может быть связанно с tcp_congestion_control? Вроде westwood помогает, хотя не понятно…
При обращении к серверу в несколько потоков по ADSL, этот таймаут часто срабатывает.
Получается как будто есть два соединения к серверу, но Linux почему-то слишком долго посылает данные по одному из них,
при этом второе соединение простаивает эти 5 секунд и случается таймаут.
tcp_congestion_control=cubic
Я так понимаю это тоже может быть связанно с tcp_congestion_control? Вроде westwood помогает, хотя не понятно…
У известного немецкого дата-центра H на нелимитированном канале 100Mbit и при пинге 60ms наблюдается такой эффект из Москвы: небольшие файлы, например картинки, скачиваются очень медленно, например картинки 10Kb-100Kb по firebug могут загружаться одинаково долго за 250ms-500ms, то есть на скорости менее 100kb/sec. При этом если загружать большой многомегабайтный файл (хоть http, хоть ftp), то видно как в начале идут те же самые 100kbps, а затем разгоняется полностью до ширины моей канала 30Mbps.
Бывает и так — страница 10kb генерируется за 10ms, по firebug отдаётся 350ms, а затем уже загрузка маленьких картинок идёт как раз уже на скорости пинга 60ms. Но стоит через пару секунд после загрузки страницы кликнуть на большую 100кб картинку — 500ms-1000ms.
CentOs 5.9 2.6.18,KeepAlive on, MaxKeepAliveRequests 100, KeepAliveTimeout 15, net.ipv4.tcp_congestion_control = bic, net.ipv4.tcp_slow_start_after_idle = 1
Вопрос — как это побороть, в какую сторону смотреть и как убрать это первоначальное затормаживание? Это именно эффект от net.ipv4.tcp_slow_start_after_idle или маленький KeepAlive? Пробую сразу после загрузки жать Ctrl+F5 до истечения таймаута KeepAlive — цифры все такие же. Или это дата-центр специально так шейпит?
Бывает и так — страница 10kb генерируется за 10ms, по firebug отдаётся 350ms, а затем уже загрузка маленьких картинок идёт как раз уже на скорости пинга 60ms. Но стоит через пару секунд после загрузки страницы кликнуть на большую 100кб картинку — 500ms-1000ms.
CentOs 5.9 2.6.18,KeepAlive on, MaxKeepAliveRequests 100, KeepAliveTimeout 15, net.ipv4.tcp_congestion_control = bic, net.ipv4.tcp_slow_start_after_idle = 1
Вопрос — как это побороть, в какую сторону смотреть и как убрать это первоначальное затормаживание? Это именно эффект от net.ipv4.tcp_slow_start_after_idle или маленький KeepAlive? Пробую сразу после загрузки жать Ctrl+F5 до истечения таймаута KeepAlive — цифры все такие же. Или это дата-центр специально так шейпит?
Вот что пишут news.ycombinator.com/item?id=1796698
ipv4.tcp_slow_start_after_idle, which is on by default on most distros, applies to keepalive connections. This causes your keepalive connection to return to slow start after TCP_TIMEOUT_INIT which is 3 seconds. Not probably want you want or expect. For example, if you have keepalives of say 10s, you'd expect that a request after say 5s would have it's congestion window fully open from previous requests, but the default behaviour is to go back to slow start, and close your congestion window back down. So you want to tune this to off on your image servers and other keepalive systems.
The tuning which I talk about is to actually increase the default initial congestion window size. The result being an advantage for non-keepalive connections and keepalives. There is no sysctl parameter that will allow for this control. This behaviour is hardcoded into the tcp stack, and hence requires direct modification and a recompiled kernel.
То есть без рекомпиляции ядра вроде никак.
ipv4.tcp_slow_start_after_idle, which is on by default on most distros, applies to keepalive connections. This causes your keepalive connection to return to slow start after TCP_TIMEOUT_INIT which is 3 seconds. Not probably want you want or expect. For example, if you have keepalives of say 10s, you'd expect that a request after say 5s would have it's congestion window fully open from previous requests, but the default behaviour is to go back to slow start, and close your congestion window back down. So you want to tune this to off on your image servers and other keepalive systems.
The tuning which I talk about is to actually increase the default initial congestion window size. The result being an advantage for non-keepalive connections and keepalives. There is no sysctl parameter that will allow for this control. This behaviour is hardcoded into the tcp stack, and hence requires direct modification and a recompiled kernel.
То есть без рекомпиляции ядра вроде никак.
Сначала обновите ядро. Начиная с 3.1 или 3.2 произошло много изменений в TCP. Также посмотрите начальный размер TCP окна через sysctl.
Ну и у вас все еще BIC в качестве congestion algo, он вообще агрессивный.
Ну и у вас все еще BIC в качестве congestion algo, он вообще агрессивный.
через некоторое время он весит систему software interrupt'ами— «вешает», может быть? 3 раза перечитал.
Спасибо за статью. Однако у меня вопрос: до этого (до вашей статьи) для меня TCP Congestion Control Algorithm-ы это были Fast Retransmit and Recovery (FRR) и Selective ACK (SACK), а в ваших примерах TCP Veno и проч. Правильно ли я понял, что BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois — это как пакеты, которые описывают работу TCP Congestion алгоритмов. Т.е. возможно в одном из этих «пакетов» также присутствует алгоритмы Fast Retransmit и Selective ACK?
Правильно ли я понял, что BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois — это как пакеты, которые описывают работу TCP Congestion алгоритмов.Да, так и есть. На последних ядрах выбор таков:
tcp_cdg.ko.xz tcp_dctcp.ko.xz tcp_diag.ko.xz tcp_bic.ko.xz tcp_hybla.ko.xz tcp_vegas.ko.xz tcp_yeah.ko.xz tcp_htcp.ko.xz tcp_illinois.ko.xz tcp_westwood.ko.xz tcp_veno.ko.xz tcp_highspeed.ko.xz tcp_scalable.ko.xz tcp_lp.ko.xzТ.е. возможно в одном из этих «пакетов» также присутствует алгоритмы Fast Retransmit и Selective ACK?Fast Retransmit реализован в Reno, вы можете его активировать следующим образом:
echo reno | sudo tee /proc/sys/net/ipv4/tcp_congestion_controlНо действительно ли вы этого хотите? Reno — классический алгоритм, современны алгоритмы, вроде YeAH, лучше.
---
Мне, кстати, вот, интересно почему столько лет прошло, а Illinois до сих пор нельзя выбрать дефолтным в конфиге ядра при компиляции :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TCP Congestion Control или Почему скорость прыгает