The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Проект по избавлению Linux-ядра от излишней сетевой буферизации

27.02.2011 23:17

Анонсировано создание экспериментального репозитория Linux-ядра - debloat-testing, созданного для реализации идей по избавлению сетевых подсистем от излишней буферизации. Репозиторий создан в рамках проекта BufferBloat.net, изучающего феномен негативного влияния промежуточной буферизации пакетов на пропускную способность, однородность потока (jitter) и время прохождения пакетов (latency). После проверки и стабилизации, обкатанные в ветке debloat-testing патчи будут направлены для включения в состав основного Linux-ядра.

Изначально термин Bufferbloat несколько месяцев назад предложил Джим Гетиc (Jim Gettys), член комитета W3C и разработчик спецификации HTTP/1.1, который в цикле статей достаточно подробно описал связь буферизации с проблемами, приводящими к возникновению дополнительных задержек и понижению пропускной способности. Последние годы актуальность проблемы значительно возросла, так как удешевление памяти привело к излишнему пристрастию производителей маршрутизаторов и коммутаторов, а также разработчиков операционных систем к дополнительной буферизации сетевых пакетов. В конечном итоге это выливается в ощутимом снижении эффективности используемых алгоритмов контроля перегрузки (TCP congestion control), в большой степени полагающихся на потери пакетов при расчете доступной пропускной способности.

Буферизация затормаживает отбрасывание пакетов, в то время как алгоритм контроля перегрузки все наращивает и наращивает скорость, используя для обратной связи начало потери пакетов. В результате, так как снижения скорости из-за начала потери пакетов вовремя не происходит, алгоритм не может подобрать нужный баланс скорости потока, соотносящийся со скоростью физического линка. При этом чем больше размер буфера, тем больше становится задержка в доставке пакетов, так как реакция алгоритма контроля перегрузки следует только после заполнения буфера. У современных маршрутизаторов размер буфера исчисляется мегабайтами, т.е. величина задержки в принятии решения о понижении скорости потока может достигать 10 сек и более. Особенно чувствительны к проблемам излишней буферизации интерактивные виды трафика, например игры и VoIP, при этом методы приоритезации (QoS), при которых для определенного вида трафика создается отдельная очередь пакетов, мало помогают решению проблемы.

Представленная ветка debloat-testing является своего рода экспериментальной площадкой для обкатывания механизмов для решения вышеотмеченных проблем - от интеграции новых механизмов контроля перегрузки, до небольших оптимизаций и модификаций текущего кода. В частности, в debloat-testing уже интегрированы планировщики потока пакетов CHOKe (CHOose and Keep) и SFB (Stochastic Fair Blue scheduler), в подсистеме mac80211 реализован алгоритм eBDP для снижения задержек в беспроводных сетях, переработаны методы работы с очередями в драйвере iwlwifi, добавлены исправления в код драйверов e1000, e1000e и ath9k. Дополнительно подготовлен набор патчей для утилиты "tc" из пакета iproute2, в которых реализованы средства для управления планировщиками CHOKe AQM и SFB.

  1. Главная ссылка к новости (https://lkml.org/lkml/2011/2/2...)
  2. OpenNews: Анализ проблем с буферизацией в современных TCP/IP сетях
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/29734-tcpip
Ключевые слова: tcpip, buffer, scheduler, patch, linux, kernel, qos, speed, latency
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, odus (ok), 08:17, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще выключили
    FreeBSD 8.2
    The TCP bandwidth delay product window limiting algorithm controlled by the sysctl(8) variable net.inet.tcp.inflight.enable is now disabled by default. It has been found that this algorithm is inefficient on a fast network with smaller RTT than 10ms. It had been enabled by default since 5.2-RELEASE, and then had been disabled only if the RTT was lesser than 10ms since 7.0-RELEASE. Pluggable TCP congestion control algorithm modules are planned to be added for the future releases.[r211538]
     
     
  • 2.4, анон (?), 10:48, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >The TCP bandwidth delay product window limiting algorithm

    Скажите, а как это относится к сабжу?

     
     
  • 3.14, pavlinux (ok), 17:56, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А это BSD, у них всё через ж...у.
    Вместо определения размера буфера, они определяют время задержки. :)
     
     
  • 4.15, northbear (ok), 20:31, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да не... Это у тебя мозги оттуда растут.
    Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста.

    А вот время задержки при прохождении пакета через роутер, это вполне конкретный параметр и измеряется он никак не в мегабайтах.
     
     
  • 5.17, pavlinux (ok), 20:56, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну конечно, и в независимости от трафика они все будут торчать в буфере 10 мс,
    пофигу что, PPP, WiFi или 10G Ethernet. Получиться этакий Stable Ping.  

     
     
  • 6.21, northbear (ok), 06:05, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не тормози... Не более 10ms. На уровне TCP не имеет значения по какому транспорту поступают пакеты в роутер.
    Если вдруг это действительно становится принципиальным, то для этого ставятся специализированные железки заточенные под обслуживание конкретного типа траффика.
     
     
  • 7.28, DFX (ok), 09:47, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    ну нифигасебе, автор уже придумал какой-то свой TCP, с буферастыми маршрутизатор... большой текст свёрнут, показать
     
     
  • 8.30, northbear (??), 15:49, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Эмоционально Про окно вы все верно сказали Только при чем тут окно 0_о Проч... текст свёрнут, показать
     
     
  • 9.33, DFX (ok), 19:33, 02/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    то не про статьюж было, а про камент с The TCP bandwidth delay product window l... большой текст свёрнут, показать
     
  • 5.20, User294 (ok), 22:30, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Для серьезных систем пох сколько памяти понадобится для буфера.

    А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание? Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то не попадались. Также не понятно зачем вообще буферизовать все и вся с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу? oO

     
     
  • 6.22, northbear (ok), 06:33, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Для серьезных систем пох сколько памяти понадобится для буфера.
    > А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание?
    > Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то
    > не попадались. Также не понятно зачем вообще буферизовать все и вся
    > с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу?
    > oO

    Ты вообще серьезное железо видел? А документацию хоть раз пробовал почитать? Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить?

    Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы. Сколько при этом система потратит памяти мне по барабану. Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины. Исходя из этого и подбирается железо.
    Это и есть "Ынтерпрайзный" подход к делу.

    А вы дома можете хоть в литрах буфера измерять. Только тип жидкости не забывайте указывать.

     

  • 1.2, stalker37 (?), 09:19, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хех... ну что же  посмотрим что из этого выйдет.. Есть где бы такое было интересно пощупать в продакшене.
     
  • 1.8, Ромка (?), 12:30, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что такое сетевая буферизация? Нет, серьёзно. Впервые слышу. :-(
     
     
  • 2.11, Аноним (-), 13:46, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Гуглить в сторону "Network buffering". На русском я пока не нашел ничего...
     
     
  • 3.12, Аноним (-), 13:50, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, например:
    http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.perf.doc/
     
  • 2.13, pavlinux (ok), 17:34, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А что такое сетевая буферизация?

    Очередь пакетов знаете? Так вот, этот дядька считает, что
    принудительное завышение размера очереди это нехорошо для сети.

     

  • 1.18, СуперАноним (?), 21:44, 28/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот только непонятно, как этот проект будет сочетаться с NAPI, который уменьшает частоту аппаратных прерываний от сетевых адаптеров именно за счёт буферизации нескольких последовательно принимаемых пакетов.
     
     
  • 2.19, User294 (ok), 22:22, 28/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Добро пожаловать в реальный мир, мир tradeoff'ов и компромиссов :). В идеальном мире было бы круто передавать данные с входа на выход с нулевой задержкой и бесконечной скоростью. В реальном так, как вы понимаете, не катит - нас забыли снабдить процессорами бесконечной мощности с нулевым временем реакции на событие вида "получена порция данных" ака "прерывание", да и сети почему-то обладают хоть и приличной но конечной скоростью передачи данных :)
     
     
  • 3.26, СуперАноним (?), 08:47, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так и я о том же ;)
     
  • 2.23, northbear (ok), 07:00, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Полагаю, это вопрос возможностей. Ядро должно уметь обрабатывать траффик с минимальными задержками. А буферы включить принципиальных проблем нет, если вам это вдруг покажется необходимым.

    А что собственно вы имеете против прерываний? Они, эти самые прерывания, для того и создавались, чтобы обрабатывать события более важные, чем текущие задачи.

     
     
  • 3.24, К.О. (?), 07:24, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко тактов на сохранение основных регистров.

    В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.

     
     
  • 4.25, К.О. (?), 07:26, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
    > контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.

    Ну и да, про аннулирование длиннющего префетча тоже молчу.

     
  • 4.31, northbear (??), 16:01, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без
    > поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко
    > тактов на сохранение основных регистров.
    > В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
    > контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.

    Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой подсистеме прерывания аппаратные.

    Не очень хорошо понимаю, что значит уменьшить число прерываний? Если данные пришли, то их надо обрабатывать. Можно конечно попробовать игнорировать прерывания, но что сетевой карте тогда делать с вашими данными?

    Может имеет смысл покупать адекватные сетевые карты которые имеют нормальный буфер?

     
     
  • 5.32, Andrey Mitrofanov (?), 18:21, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой
    > подсистеме прерывания аппаратные.

    Иногда эффективнее поллить, говорят... Отключив прерывания, о ужас.

    google:NAPI

     
  • 5.34, К.О. (?), 17:22, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Про поллинг что-нибудь слышали? Или про обработку нескольких пакетов в прерывание? А это - уже буферизация, и повышение latency.
     
  • 3.27, СуперАноним (?), 08:56, 01/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >А что собственно вы имеете против прерываний?

    Если они происходят часто, то большой процент времени всяких там переключений аппаратных и программных. Поэтому, собственно, разрабатывашие NAPI и озаботились чтобы снизить частоту прерываний и за счёт этого увеличить пропускную способность сетевой подсистемы. И да, пропускная способность и латентность находятся в некотором антагонизме.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру