WiFi на Linux стане швидше

нехай краще невелика, але фейербаховская...
Віктор Пєлєвін «Покоління Пі»
Недавній реліз ядра Linux 4.9 відмінний привід розповісти про майбутній розгоні WiFi. Відразу обмовлюся — пост не про те, як збільшити зону покриття або змінювати регуляторні домени. Нічого такого робити не треба, достатньо оновити ядро після того, як патчі буфероборца Dave Täht будуть в стабільній гілці.


Значне підвищення швидкості досягнуто за рахунок зменшення затримки [1] і надлишкової буферизації [2] в мережі. Розробникам довелося заради цього перелопатити
mac80211
, прибрати дещо зверху, додати знизу і після цього затримки в мережі скоротилися на порядок. Ціна питання? Патч до 200 рядків. Подробиці під катом.
Той самий Bufferbloat
Bufferbloat — це зайва буферизація в мережевому обладнанні провайдера, що призводить до небажаних затримок передачі даних. При досить завантаженому каналі кожне з'єднання від'їдає мілісекунди, які потім перетворюються в секунди, а іноді і хвилини очікування. Якщо мережна затримка дорівнює 1 секунді, то slashdot.org буде завантажуватися цілих 4 хвилини!
# flent -300 l-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.8 s
Downloaded: 62 files, 1.8 M in 0.9 s (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
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.