Анонсировано (https://lkml.org/lkml/2011/2/25/402) создание экспериментального репозитория Linux-ядра - debloat-testing, созданного для реализации идей по избавлению сетевых подсистем от излишней буферизации. Репозиторий создан в рамках проекта BufferBloat.net (http://www.bufferbloat.net), изучающего феномен негативного влияния промежуточной буферизации пакетов на пропускную способность, однородность потока (jitter (http://en.wikipedia.org/wiki/Packet_delay_variation)) и время прохождения пакетов (latency (http://en.wikipedia.org/wiki/Latency_%28engineering...После проверки и стабилизации, обкатанные в ветке debloat-testing патчи будут направлены для включения в состав основного Linux-ядра.Изначально термин Bufferbloat несколько месяцев назад предложил (http://gettys.wordpress.com/what-is-bufferbloat-anyway/) Джим Гетиc (Jim Gettys), член комитета W3C и разработчик спецификации HTTP/1.1, который в цикле статей (http://www.opennet.me/opennews/art.shtml?num=29191) достато...
URL: https://lkml.org/lkml/2011/2/25/402
Новость: http://www.opennet.me/opennews/art.shtml?num=29734
Вообще выключили
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]
>The TCP bandwidth delay product window limiting algorithmСкажите, а как это относится к сабжу?
А это BSD, у них всё через ж...у.
Вместо определения размера буфера, они определяют время задержки. :)
Да не... Это у тебя мозги оттуда растут.
Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста.
А вот время задержки при прохождении пакета через роутер, это вполне конкретный параметр и измеряется он никак не в мегабайтах.
Ну конечно, и в независимости от трафика они все будут торчать в буфере 10 мс,
пофигу что, PPP, WiFi или 10G Ethernet. Получиться этакий Stable Ping.
Не тормози... Не более 10ms. На уровне TCP не имеет значения по какому транспорту поступают пакеты в роутер.
Если вдруг это действительно становится принципиальным, то для этого ставятся специализированные железки заточенные под обслуживание конкретного типа траффика.
ну нифигасебе, автор уже придумал какой-то свой TCP, с буферастыми маршрутизаторами и их преферансами в L4 ?а ничего, что результат перемножения пропускной_способности_канала(порта) на задержку(Round Trip Time), основополагающая величина для исчисления окна TCP ?
http://en.wikipedia.org/wiki/Bandwidth-delay_product
"A high bandwidth-delay product is an important problem case in the design of protocols such as TCP in respect of performance tuning, because the protocol can only achieve optimum throughput if a sender sends a sufficiently large quantity of data before being required to stop and wait until a confirming message is received from the receiver, acknowledging successful receipt of that data.">> Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста.
вот про таких в статье и написано... цена падает -> доступные размеры памяти растут быстро, скорость работы этой памяти - _нет_. войдя в буфер с одного конца, данные уйдут только с другого пока не пройдут всю его величину. больше буфер -> дольше обработка.
задержка(delay) теперь состоит не из RTT, а из RTT+обработка_буфера.на что автору так уклончиво пытались намекнуть -
1) увеличиваем bandwidth (PPP -> WiFi -> 10G Ethernet)
2) увеличиваем буфер (увеличиваем delay)
3) значит, заменяем _возможный_минимальный_ bandwidth(некий_тощий_порт)*delay(RTT_между_данными_узлами_сети) на bandwidth(некий_жирный_порт)*delay(RTT_между_данными_узлами_сети+обработка_жирного_буфера)
4) алгоритм расчёта окна работает не оптимизировано, latency повышается, по сравнению с тем, чего можно было добиться, если не дрочить на дешёвую память.
более того, если алгоритм вообще не учитывает влияние буферизации, то у него может сложиться "ошибочное впечатление" о максимальной ёмкости канала в целом.
сложная концепция ? вроде в новости доходчиво объяснили.>> Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить?
действительно, как ?
>> Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы.
ещё как!
>> Сколько при этом система потратит памяти мне по барабану.
а не должно, если разговор о коммутации/маршрутизации и latency.
поясняю: RTT - это параметр, обределяющийся совокупностью _каналов_ от одного узла, до другого в сети. если Ваше железо - не говно, то оно делает коммутацию/маршрутизацию на wire-speed и на него не влияет. буфера для коммутации и маршрутизации в "серьезных маршрутизаторах" находятся явно не в обычной оперативе, а отдельном/ых чипе/ах этих самых "специализированных железок" и размером-то небольшим(именно из расчёта для максимальной пропускной способности, и _не больше_).
а потом, больше, чем там напаяно, оно явно не вырастет, значит, если что - пойдёт в медленную оперативу.http://www.fujitsu.com/emea/services/microelectronics/networ.../
вот, посмотри, автор, где буфера для коммутации живут. сколько там буфера для 10Г ? целых _2Мбайта_!это если разговор про "специальные железки", а не писюк с DDR3 и BSD'ёй.
что касается BSD, в частности, и ОС на двух узлах(_на узлах, получателе и отправителе_), в целом - RTT оно не улучшит, хоть обпукается, а вот размер буфера - какбэ оператор должен иметь параметр, чтобы настраивать.
а алгоритмы должны это учитывать.>> Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины.
мы всё ещё о промежуточных маршрутизаторах, занимающихся именно маршрутизацией, а не фильтрацией там или NAT'ом ? можно посмотреть таблицу, или график там, зависимости времени обработки пакета от нагрузки (причём, нагрузки - до заявленого максимального pps) для какой-нибудь железки ? и заодно узнать, _как это всё связано с алгоритмами расчёта окна TCP_ ?
короче говоря, злоупотребление горами говённой памяти - не к добру, особенно для latency, хоть в сетях (читаем новость ещё раз), хоть в звуке (jack - наше всё), хоть в видео (многие ли слыхали про попытки, в последнее время, избавиться от двойной и тройной буферизации в X и toolkit'ах ? а они есть. даже злобная nvidia подключилась).
PS: delay & latency & QoS в картинках - http://www.agilitycom.com/product-literature/Optimization_WP...
Эмоционально... Про окно вы все верно сказали. Только при чем тут окно? 0_о
Прочитайте статью Transmission Control Protocol про flow control и congestion control. Вам будет понятно о чем говорится в новости.Про память, еще раз... Меня не интересует размер буфера. Меня интересует время задержки. И если железо не может мне гарантировать в данном узле при данной нагрузке то время задержки которое я считаю приемлемым для себя, то такое железо мне просто не нужно.
Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.Я знаю, что такое аппаратные буферы. К буферам о которых говорится в новости они не имеют никакого отношения.
Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть. Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах.
Я в свое время тоже этому удивился. Теперь же мне непонятно как может быть иначе. :)еще раз... аппаратные буферы нерасширяемы, т.е. как только они переполняются, система вынуждена дропать пакеты. Удаленная сторона, видя, что пакеты теряются, сообщает отправителю, что надо снизить скорость передачи.
Когда память стала дешевой, кто-то решил, что программные автоматически расширяемые за счет оперативки буферы это круто. С одной стороны выглядит неплохо, пакеты не теряются, никаких ретрансмиссий нет. Но по итогу работа алгоритмов управления потоками и заторами TCP оказалась полностью нарушенной, о чем, собственно и говорится в новости.
>> Только при чем тут окно? 0_ото не про статьюж было, а про камент с "The TCP bandwidth delay product window limiting algorithm controlled by the sysctl(8) variable net.inet.tcp.inflight.enable"
>> Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.
о чём речь в каментах и была. про soft-router'ы на BSD, да и вообще ковыряние в сетевой подсистеме BSD и Linux
>> Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть.
в этом конкретном случае размер буфера похоже не тольк не настраивался, но и не учитывался алгоритмом вообще.
>> Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах.
ммм, ничего про это не знаю, но может быть подразумевается, что поток данных звука там с постоянным bitrate, да и вообще какого-то одного формата ? и указано так мол "вот на столько ms эта мера по снижению jitter добавит к задержкам передачи речи, а сколько это в байтах и насколько большие отклонения сгладит - сами посчитаете"
>> Когда память стала дешевой, кто-то решил, что программные автоматически расширяемые за счет оперативки буферы это круто. С одной стороны выглядит неплохо, пакеты не теряются, никаких ретрансмиссий нет. Но по итогу работа алгоритмов управления потоками и заторами TCP оказалась полностью нарушенной, о чем, собственно и говорится в новости.
именно по-этому фразы вроде "Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста." бесят. специалисты и необделённые деньгами - не всегда одно и тоже. специалисты soft router'ов и разработчики ядра небось тоже негодуют.
и я не уверен, что ядро Linux вообще выделяет бесконечные программные буферы, тем более выделяет вообще, если знает, что на текущем железе есть аппаратные. хотя может быть именно о выпиливании такого поведения и подразумевалось под "добавлены исправления в код драйверов e1000, e1000e и ath9k", но всё равно маловероятно.
да и не факт вообще, что в статье речь только о soft маршрутизатор или только о конечных узлах. может быть имелось ввиду, что алгоритмы congestion control (cat /proc/sys/net/ipv4/tcp_available_congestion_control, их много) на узлах обламываются из-за запредельной буферизации на soft-router'ах ?
> Для серьезных систем пох сколько памяти понадобится для буфера.А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание? Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то не попадались. Также не понятно зачем вообще буферизовать все и вся с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу? oO
>> Для серьезных систем пох сколько памяти понадобится для буфера.
> А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание?
> Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то
> не попадались. Также не понятно зачем вообще буферизовать все и вся
> с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу?
> oOТы вообще серьезное железо видел? А документацию хоть раз пробовал почитать? Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить?
Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы. Сколько при этом система потратит памяти мне по барабану. Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины. Исходя из этого и подбирается железо.
Это и есть "Ынтерпрайзный" подход к делу.А вы дома можете хоть в литрах буфера измерять. Только тип жидкости не забывайте указывать.
Хех... ну что же посмотрим что из этого выйдет.. Есть где бы такое было интересно пощупать в продакшене.
А что такое сетевая буферизация? Нет, серьёзно. Впервые слышу. :-(
Гуглить в сторону "Network buffering". На русском я пока не нашел ничего...
Вот, например:
http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/...
> А что такое сетевая буферизация?Очередь пакетов знаете? Так вот, этот дядька считает, что
принудительное завышение размера очереди это нехорошо для сети.
Вот только непонятно, как этот проект будет сочетаться с NAPI, который уменьшает частоту аппаратных прерываний от сетевых адаптеров именно за счёт буферизации нескольких последовательно принимаемых пакетов.
Добро пожаловать в реальный мир, мир tradeoff'ов и компромиссов :). В идеальном мире было бы круто передавать данные с входа на выход с нулевой задержкой и бесконечной скоростью. В реальном так, как вы понимаете, не катит - нас забыли снабдить процессорами бесконечной мощности с нулевым временем реакции на событие вида "получена порция данных" ака "прерывание", да и сети почему-то обладают хоть и приличной но конечной скоростью передачи данных :)
Ну так и я о том же ;)
Полагаю, это вопрос возможностей. Ядро должно уметь обрабатывать траффик с минимальными задержками. А буферы включить принципиальных проблем нет, если вам это вдруг покажется необходимым.А что собственно вы имеете против прерываний? Они, эти самые прерывания, для того и создавались, чтобы обрабатывать события более важные, чем текущие задачи.
Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко тактов на сохранение основных регистров.В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.
> В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
> контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.Ну и да, про аннулирование длиннющего префетча тоже молчу.
> Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без
> поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко
> тактов на сохранение основных регистров.
> В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
> контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой подсистеме прерывания аппаратные.
Не очень хорошо понимаю, что значит уменьшить число прерываний? Если данные пришли, то их надо обрабатывать. Можно конечно попробовать игнорировать прерывания, но что сетевой карте тогда делать с вашими данными?
Может имеет смысл покупать адекватные сетевые карты которые имеют нормальный буфер?
> Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой
> подсистеме прерывания аппаратные.Иногда эффективнее поллить, говорят... Отключив прерывания, о ужас.
google:NAPI
Про поллинг что-нибудь слышали? Или про обработку нескольких пакетов в прерывание? А это - уже буферизация, и повышение latency.
>А что собственно вы имеете против прерываний?Если они происходят часто, то большой процент времени всяких там переключений аппаратных и программных. Поэтому, собственно, разрабатывашие NAPI и озаботились чтобы снизить частоту прерываний и за счёт этого увеличить пропускную способность сетевой подсистемы. И да, пропускная способность и латентность находятся в некотором антагонизме.