Wi-Fi на Linux станет быстрее

    пусть лучше небольшая, но фейербаховская...
    Виктор Пелевин «Поколение Пи»

    Недавний релиз ядра Linux 4.9 отличный повод рассказать о предстоящем разгоне WiFi. Сразу оговорюсь — пост не о том, как увеличить зону покрытия или менять регуляторные домены. Ничего такого делать не надо, достаточно обновить ядро после того, как патчи буфероборца Dave Täht будут в стабильной ветке.



    Значительное повышение скорости достигнуто за счет уменьшения задержки [1] и избыточной буферизации [2] в сети. Разработчикам пришлось ради этого перелопатить mac80211, убрать кое-что сверху, добавить снизу и после этого задержки в сети сократились на порядок. Цена вопроса? Патч в 200 строк. Подробности под катом.


    Тот самый Bufferbloat


    Bufferbloat — это излишняя буферизация в сетевом оборудовании провайдера, что приводит к нежеланным задержкам передачи данных. При достаточно загруженном канале каждое соединение отъедает миллисекунды, которые затем превращаются в секунды, а иногда и минуты ожидания. Если сетевая задержка равна 1 секунде, то slashdot.org будет загружаться целых 4 минуты!


    # flent -l 300 -H server –streams=12 tcp_ndown &
    # wget -E -H -k -K -p https://www.slashdot.org
    ...
    FINISHED --2016-10-22 13:43:35--
    Total wall clock time: 232.8s
    Downloaded: 62 files, 1.8M in 0.9s (77KB/s)

    Первая команда использует питоновский wrapper для netperf, это мощный инструмент проведения контрольных замеров[3] сетевых подключений.


    -l 300 #тест длится 5 минут
    -H server #подключиться к хосту server
    -streams=12 tcp_ndown #12 потоков tcp download

    Flent загружает канал так, чтобы соединение устанавливалось с секундной задержкой. Установка соединения заняла 99.6% времени исполнения, в результате реальная скорость упала до жалких 77 KB/с. При нулевой задержке та же страница загружается за 8 секунд. Таким образом время кругового пути[4] и задержка имеют большее значение, чем пропускная способность.


    На стороне провайдера ИБ носит характер эпидемии, но и на пользовательском оборудовании его хватает. Довольно долго каждый сетевой драйвер проектировался с расчетом на нереально высокие потребности буферизации данных, так как разработчики оптимизировали планировщик пакетов для самых высоких скоростей. Однако IRL их редко используют во время WiFi подключения. Вот из-за чего котики загружаются медленно, а видео-звонки превращаются в пытку. Проверьте вашу ИБ без СМС и регистрации.


    Неприятность в том, что основной bufferbloat на стороне провайдера, исправив ситуацию там, получаешь прирост скорости соединения на халяву. Speedtest ISP Xfinity и Google Fiber.


    Не сказать, что дело ограничивалось одним лишь нытьем. Начиная с Linux 3.3 вышла целая серия исправлений и оптимизаций направленных на устранение ИБ.


    • Linux 3.3: Byte Queue Limits
    • Linux 3.4 RED bug fixes & IW10 added & SFQRED
    • Linux 3.5 Fair/Flow Queuing packet scheduling (fq_codel, codel)
    • Linux 3.7 TCP small queues (TSQ)
    • Linux 3.12 TSO/GSO improvements
    • Linux 3.13 Host FQ + Pacing (sch_fq)
    • Linux 3.15 Change to microseconds from milliseconds throughout networking kernel
    • Linux 3.17 Network Batching API
    • Linux 4.9 BBR (Bottleneck Bandwidth and RTT)

    Последний в этой серии исправлений алгоритм BBR. Новость с opennet.ru.


    В состав ядра включена реализация предложенного компанией Google алгоритма контроля перегрузки TCP (congestion control) — BBR (Bottleneck Bandwidth and RTT), успешно применяемого для увеличения пропускной способности и сокращения задержек передачи данных для трафика с google.com и YouTube. BBR требует внесения изменений только на стороне отправителя, программное обеспечение сетевой инфраструктуры и принимающей стороны остаётся без изменений. Вместо использования потери пакетов как индикатора перегрузки, в BBR применяются методы моделирования канала связи, прогнозирующие имеющуюся пропускную способность через последовательные проверки и оценку времени приема-передачи (RTT), но не доводя до потери пакетов или задержек в передаче. На начальной стадии соединения BBR оценивает потолок пропускной способности канала, затем снижает интенсивность отправки для разгрузки очереди и переходит в режим корректировки, то повышая, то снижая интенсивность отправки, балансируя между максимальной пропускной способностью и незаполненностью очереди пакетов;


    Эти изменения затронули почти все сетевые протоколы, однако обошли стороной WiFi и LTE. Так не могло долго продолжаться и за WiFi взялись всерьез. Проект Make WiFi Fast собрал сотни участников во главе с командой ядерных сетевиков.


    Терминология


    • QDisc или Queuing Discipline — обычный FIFO планировщик, он находится между IP стеком и драйвером.




    • Планировщик fq_codel не так прост. О нем уже писали на Хабре, поэтому не буду повторяться.

    fq_codelодин из самых эффективных и современных алгоритмов, использующий AQM.

    • TXOP — transmit opportunity, попытка отправки.

    Как патчами разгоняли WiFi


    Dave Täht, который уже на раз спасал интернет за последние шесть лет, атаковал проблему с помощью новых и лучших бенчмарков, которые самому же пришлось разрабатывать. Довольно популярный в научной среде и за ее пределами Iperf3, вообще оказался профнепригодным, так как по умолчанию предполагает нереальные 100 ms ИБ.


    while( testing) 
        sleep 100ms
        while( total_bytes_sent / total_elapsed_time < target_rate)
           transmit buffer of data

    Так было до патча. Обратите внимание на огромные задержки в > 10 на верхнем и нижнем уровне WiFi стека.





    • QDisc убрали напрочь. Очередь теперь формируется по станциям и продвигается по круговому циклу, a. k. a. Round Robin Fair Queuing.
    • Буферизация перешла на уровень промежуточного планировщика MAC80211, который управляется со стороны fq_codel. у него минимальный размер, не больше 2 TXOP.
    • Минимум буферизации в драйвере, самое большое 2 пула TXOP (1.2-10ms): 1 готовый агрегированный фрейм для повторной попытки и еще 1 на подхвате.


    MAC80211 больше не складирует пакеты на нижнем уровне драйвера, а отправляет их промежуточному планировщику, докладывает об этом драйверу и тот забирает их по мере поступления. Благодаря этому MAC80211 имеет больше информации о том, когда происходит передача данных. Задержки от буферизации благодаря этому составили всего 2-12 ms.


    Чего удалось достичь


    ИБ удалось избыть настолько, что задержки снизились с пиковых значений 1-2 секунд до 40 msec. Наиболее наглядной иллюстрацией будет картинка на которой видны WiFi сессии на 100 рабочих станций до и после патча.


    До патча, лишь 5 станций успешно стартовали. Чудовищные > 15 секунд тормоза. Кликабельно.





    После патча, все станции успешно стартовали. Задержки приемлемые 150-300 msec. Кликабельно.



    Теперь ложка дегтя. Пока лишь драйвера ath9k полностью поддерживают все эти новшества, ath10k уже почти готов. Остальным пока придется подождать, но уверен, остальные драйвера тоже будут активно дорабатываться после того, как патчи попадут в стабильную ветку.


    Использованные материалы и полезные ссылки





    1. Latency
    2. Bufferbloat
    3. Benchmark
    4. Round Trip Time
    Share post

    Similar posts

    Comments 19

      +3
      Поддержка BQL есть еще не во всех драйверах Ethernet-плат, а Wi-Fi и подавно. Cake все еще не приняли в ядро. Радует, что гугловский BBR уже есть в ядре, но использовать его на клиентской стороне имеет смысл, по большому счету, только в том случае, если у вас либо очень асимметричный канал (что типично, например, для США: 100 Мбит/с прием, 5 мбит/с отдача), и загруженная отдача влияет на скорость приема и задержки, либо если вы просто много отдаете, например, у вас сидбокс.

      Увы, потребуется много лет (не меньше трех) для того, чтобы мы увидели эти новшества в типичных домашних роутерах. Да и владельцы сайтов (и серверов в целом) тоже вряд ли будут принудительно использовать BBR вместо Cubic, поможет только установка его по умолчанию (как это было с fq_codel).
        0
        Что такое Cake и Cubic?
        BQL это Byte Queue Limits?
          0
          Алгоритмы управления, которые призваны делать передачу данных протоколом более оптимальной с учётом своей спицифики.
          Вцелом о TCP Congestion Control
          BQL
            0
            Cake — ещё одна дисциплина очереди, которая разрабатывается в рамках проекта bufferbloat. Подробнее тут.
            Cubic — один из алгоритмов управления перегрузкой (congestion control) в tcp. Используется по-умолчанию. Статья в википедии.
              +5
              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, либо настраивать шейпер.
                +1
                Что-то странное про Cubic пишешь. В FreeBSD используется по-умолчанию NewReno, в Windows — Compound TCP. Про OS X не знаю, но предположу, что тоже не Cubic. Для андроид тоже предпочтительней будет использовать не CUBIC, который лучше работает на Long Fat Network, а для беспроводных протоколов будет лучше выбрать что-то другое, например, Westwood.

                Алгоритмы предотвращения перегрузок тем и хороши, что можно менять безболезненно на передающей стороне, принимающую сторону менять не надо.
                  0
                  Для андроид тоже предпочтительней будет использовать не CUBIC, который лучше работает на Long Fat Network, а для беспроводных протоколов будет лучше выбрать что-то другое, например, Westwood.

                  А почему нельзя сделать это переключаемым на уровне пользователя? Чтобы либо вручную можно было легко и быстро сделать такой «твик», либо автоматически в зависимости от типа соединения? Я, например, с андроидофона в Сеть выхожу исключительно по WiFi, нормальные люди вроде тоже большую часть времени проводят в офисе и дома, где кабельный/DSL канал раздаётся через WiFi и периодически ненадолго переключаются на GPRS/3G/LTE.
            • UFO just landed and posted this here
              0
              Поправьте меня если я ошибаюсь. Теперь, если на роутере стоит шейпинг c использованием СoDel, а отправляющая сторона задействовала BBR, то у всех будут потери пакетов? CoDel уменьшает задержку, BBR на нее ориентируется. Алгоритмы по описанию друг о друге не в курсе и работают в противофазе. Жесть.
                0

                Если я правильно понял, то без BBR потери пакетов — единственный способ узнать о перегруженности сети. То есть алгоритм BBR в этом плане хуже сделать не может, ибо некуда.

                +2
                Цена вопроса? Патч в 200 строк.

                Не нашёл в статье ссылку на патч. Было бы интересно взглянуть.
                +2
                На Windows такая проблема не проявляется?
                  0
                  Эта проблема касается абсолютно всех ОС, так как справедливое распределение эфирного времени достигается на стороне точки доступа. Как правило, это роутер с WIFI.
                  0
                  Это все хорошо но на я до сих пор не могу заставить свой вай фай выдать подключение на 300Мбс, только 150. А на винде без проблем выдавалось 300Мбс. И это еще пришлось погуглить чтоб найти правильный бубен. Пишут что это такая давно известная проблема с картами от интел. :(
                    0
                    Познавательное видео https://www.youtube.com/watch?v=YCimAYClv3c

                    Only users with full accounts can post comments. Log in, please.