The OpenNET Project / Index page

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

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

Анонсировано создание экспериментального репозитория 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
Тип: К сведению
Ключевые слова: tcpip, buffer, scheduler, patch, linux, kernel, qos, speed, latency
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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:
    Заголовок:
    Текст:


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