Комментарии 19
Поддержка BQL есть еще не во всех драйверах Ethernet-плат, а Wi-Fi и подавно. Cake все еще не приняли в ядро. Радует, что гугловский BBR уже есть в ядре, но использовать его на клиентской стороне имеет смысл, по большому счету, только в том случае, если у вас либо очень асимметричный канал (что типично, например, для США: 100 Мбит/с прием, 5 мбит/с отдача), и загруженная отдача влияет на скорость приема и задержки, либо если вы просто много отдаете, например, у вас сидбокс.
Увы, потребуется много лет (не меньше трех) для того, чтобы мы увидели эти новшества в типичных домашних роутерах. Да и владельцы сайтов (и серверов в целом) тоже вряд ли будут принудительно использовать BBR вместо Cubic, поможет только установка его по умолчанию (как это было с fq_codel).
Увы, потребуется много лет (не меньше трех) для того, чтобы мы увидели эти новшества в типичных домашних роутерах. Да и владельцы сайтов (и серверов в целом) тоже вряд ли будут принудительно использовать BBR вместо Cubic, поможет только установка его по умолчанию (как это было с fq_codel).
Что такое Cake и Cubic?
BQL это Byte Queue Limits?
BQL это Byte Queue Limits?
Алгоритмы управления, которые призваны делать передачу данных протоколом более оптимальной с учётом своей спицифики.
Вцелом о TCP Congestion Control
BQL
Вцелом о TCP Congestion Control
BQL
Cubic — алгоритм управления перегрузкой TCP-потока (TCP congestion control algorithm), используется по умолчанию в Windows, Linux и OS X. Он очень старый и не
подходит под реалии современного интернета, но какой-то хорошей, надежной замены ему до сих пор не было: другие алгоритмы либо показывали улучшения в частных
случаях, либо не всегда корректно работали с Cubic (а это очень важно, ведь на подавляющем большинстве устройств в интернете именно он и используется). Быть
может, вы замечали, что скорость закачки прыгает, доходя до максимально возможного значения канала, затем скачкообразно уменьшаясь, затем снова увеличиваясь —
это Cubic виноват. Надеюсь, его заменят на BBR по умолчанию в следующих версиях ядра Linux.
BQL — Byte Queue Limits — подсистема, которая сообщает ОС, сколько пакетов находится в очереди на отправку во внутреннем буфере сетевой карты, и управляет им.
Звучит ерундово, зато позволяет определять излишнюю буферизацию отправляемых данных и подстраивать размер очереди, чтобы ее минимизировать. Поддержка BQL должна
быть реализована в драйвере конкретного сетевого устройства, и уже есть во многих драйверах проводных устройств (но не во всех), и в меньшинстве драйверов
беспроводных устройств.
Cake — новая разработка, которая совмещает в себе менеджер управления очередью (AQM, active queue management), шейпер (на замену HTB), «умный» классификатор
(diffserv), и корректно работает с различными видами offloading (совмещение нескольких маленьких пакетов в один большой, чтобы не так часто обрабатывать прерывания сетевой карты, экономя процессорное время). В идеале, Cake старается управлять очередью так, чтобы разговор через VoIP не булькал, когда вы активно качаете и раздаете торренты, а задержка перед началом открытия веб-страницы была бы на таком же низком уровне, как если бы вы ничего не качали. Если говорить упрощенно, это такая современная комплексная замена fq_codel и HTB (хотя можно использовать и отдельные части Cake, например, только шейпер, вместе с fq_codel). Чтобы Cake хорошо работал, нужно либо использовать драйвер с поддержкой BQL, либо настраивать шейпер.
подходит под реалии современного интернета, но какой-то хорошей, надежной замены ему до сих пор не было: другие алгоритмы либо показывали улучшения в частных
случаях, либо не всегда корректно работали с Cubic (а это очень важно, ведь на подавляющем большинстве устройств в интернете именно он и используется). Быть
может, вы замечали, что скорость закачки прыгает, доходя до максимально возможного значения канала, затем скачкообразно уменьшаясь, затем снова увеличиваясь —
это Cubic виноват. Надеюсь, его заменят на BBR по умолчанию в следующих версиях ядра Linux.
BQL — Byte Queue Limits — подсистема, которая сообщает ОС, сколько пакетов находится в очереди на отправку во внутреннем буфере сетевой карты, и управляет им.
Звучит ерундово, зато позволяет определять излишнюю буферизацию отправляемых данных и подстраивать размер очереди, чтобы ее минимизировать. Поддержка BQL должна
быть реализована в драйвере конкретного сетевого устройства, и уже есть во многих драйверах проводных устройств (но не во всех), и в меньшинстве драйверов
беспроводных устройств.
Cake — новая разработка, которая совмещает в себе менеджер управления очередью (AQM, active queue management), шейпер (на замену HTB), «умный» классификатор
(diffserv), и корректно работает с различными видами offloading (совмещение нескольких маленьких пакетов в один большой, чтобы не так часто обрабатывать прерывания сетевой карты, экономя процессорное время). В идеале, Cake старается управлять очередью так, чтобы разговор через VoIP не булькал, когда вы активно качаете и раздаете торренты, а задержка перед началом открытия веб-страницы была бы на таком же низком уровне, как если бы вы ничего не качали. Если говорить упрощенно, это такая современная комплексная замена fq_codel и HTB (хотя можно использовать и отдельные части Cake, например, только шейпер, вместе с fq_codel). Чтобы Cake хорошо работал, нужно либо использовать драйвер с поддержкой BQL, либо настраивать шейпер.
Что-то странное про Cubic пишешь. В FreeBSD используется по-умолчанию NewReno, в Windows — Compound TCP. Про OS X не знаю, но предположу, что тоже не Cubic. Для андроид тоже предпочтительней будет использовать не CUBIC, который лучше работает на Long Fat Network, а для беспроводных протоколов будет лучше выбрать что-то другое, например, Westwood.
Алгоритмы предотвращения перегрузок тем и хороши, что можно менять безболезненно на передающей стороне, принимающую сторону менять не надо.
Алгоритмы предотвращения перегрузок тем и хороши, что можно менять безболезненно на передающей стороне, принимающую сторону менять не надо.
Для андроид тоже предпочтительней будет использовать не CUBIC, который лучше работает на Long Fat Network, а для беспроводных протоколов будет лучше выбрать что-то другое, например, Westwood.
А почему нельзя сделать это переключаемым на уровне пользователя? Чтобы либо вручную можно было легко и быстро сделать такой «твик», либо автоматически в зависимости от типа соединения? Я, например, с андроидофона в Сеть выхожу исключительно по WiFi, нормальные люди вроде тоже большую часть времени проводят в офисе и дома, где кабельный/DSL канал раздаётся через WiFi и периодически ненадолго переключаются на GPRS/3G/LTE.
НЛО прилетело и опубликовало эту надпись здесь
Поправьте меня если я ошибаюсь. Теперь, если на роутере стоит шейпинг c использованием СoDel, а отправляющая сторона задействовала BBR, то у всех будут потери пакетов? CoDel уменьшает задержку, BBR на нее ориентируется. Алгоритмы по описанию друг о друге не в курсе и работают в противофазе. Жесть.
Цена вопроса? Патч в 200 строк.
Не нашёл в статье ссылку на патч. Было бы интересно взглянуть.
И где же там поддержка планировщика для ath10k устройств?
Не вводите людей в заблуждение.
Не вводите людей в заблуждение.
The lastest 2 patchsets (for airtime fairness) for lede — not yet submitted there — are here: https://kau.toke.dk/git/lede/
An unofficial patchset that applies on top of net-next (for ath9k and ath10k), and .deb files for ubuntu is here: http://www.taht.net/~d/airtime-8/
Название одного из файлов в архиве airtime.patches.tgz по ссылке http://www.taht.net/~d/airtime-8/ — 0005-Revert-ath10k-disable-wake_tx_queue-for-older-device.patch
На Windows такая проблема не проявляется?
Это все хорошо но на я до сих пор не могу заставить свой вай фай выдать подключение на 300Мбс, только 150. А на винде без проблем выдавалось 300Мбс. И это еще пришлось погуглить чтоб найти правильный бубен. Пишут что это такая давно известная проблема с картами от интел. :(
Познавательное видео https://www.youtube.com/watch?v=YCimAYClv3c
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Wi-Fi на Linux станет быстрее