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, 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 +/
    Скажите, а как это относится к сабжу ... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.14, pavlinux, 17:56, 28/02/2011 [^] [ответить] [смотреть все]  
  • +2 +/
    А это BSD, у них всё через ж у Вместо определения размера буфера, они опреде... весь текст скрыт [показать]
     
     
  • 4.15, northbear, 20:31, 28/02/2011 [^] [ответить] [смотреть все]  
  • –1 +/
    Да не Это у тебя мозги оттуда растут Для серьезных систем пох сколько памят... весь текст скрыт [показать]
     
     
  • 5.17, pavlinux, 20:56, 28/02/2011 [^] [ответить] [смотреть все]  
  • +1 +/
    Ну конечно, и в независимости от трафика они все будут торчать в буфере 10 мс, ... весь текст скрыт [показать]
     
     
  • 6.21, northbear, 06:05, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Не тормози Не более 10ms На уровне TCP не имеет значения по какому транспорт... весь текст скрыт [показать]
     
     
  • 7.28, DFX, 09:47, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    ну нифигасебе, автор уже придумал какой-то свой TCP, с буферастыми маршрутизатор... весь текст скрыт [показать]
     
     
  • 8.30, northbear, 15:49, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Эмоционально Про окно вы все верно сказали Только при чем тут окно 0_о Проч... весь текст скрыт [показать]
     
     
  • 9.33, DFX, 19:33, 02/03/2011 [^] [ответить] [смотреть все]  
  • +/
    то не про статьюж было, а про камент с The TCP bandwidth delay product window l... весь текст скрыт [показать]
     
  • 5.20, User294, 22:30, 28/02/2011 [^] [ответить] [смотреть все]  
  • +/
    А что система делает если памяти не хватит Катастрофически подыхает Заваливает... весь текст скрыт [показать]
     
     
  • 6.22, northbear, 06:33, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Ты вообще серьезное железо видел А документацию хоть раз пробовал почитать Ты ... весь текст скрыт [показать]
     
     ....нить скрыта, показать (10)

  • 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 i... весь текст скрыт [показать]
     
  • 2.13, pavlinux, 17:34, 28/02/2011 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Очередь пакетов знаете Так вот, этот дядька считает, что принудительное завыше... весь текст скрыт [показать] [показать ветку]
     
  • 1.18, СуперАноним, 21:44, 28/02/2011 [ответить] [смотреть все]  
  • +/
    Вот только непонятно, как этот проект будет сочетаться с NAPI, который уменьшает частоту аппаратных прерываний от сетевых адаптеров именно за счёт буферизации нескольких последовательно принимаемых пакетов.
     
     
  • 2.19, User294, 22:22, 28/02/2011 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Добро пожаловать в реальный мир, мир tradeoff ов и компромиссов В идеальном ... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.26, СуперАноним, 08:47, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Ну так и я о том же ;)
     
  • 2.23, northbear, 07:00, 01/03/2011 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Полагаю, это вопрос возможностей Ядро должно уметь обрабатывать траффик с миним... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.24, К.О., 07:24, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без поддержки многозадачност... весь текст скрыт [показать]
     
     
  • 4.25, К.О., 07:26, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Ну и да, про аннулирование длиннющего префетча тоже молчу ... весь текст скрыт [показать]
     
  • 4.31, northbear, 16:01, 01/03/2011 [^] [ответить] [смотреть все]  
  • +/
    Одно но Вы знаете какой-то другой способ работать с железом В сетевой подсис... весь текст скрыт [показать]
     
     
  • 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-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor TopList