forum.opennet.ru - "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." (26)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
Сообщение от opennews (ok) on 28-Фев-11, 08:17
Анонсировано (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.dev/opennews/art.shtml?num=29191) достато... URL: https://lkml.org/lkml/2011/2/25/402 Новость: http://www.opennet.dev/opennews/art.shtml?num=29734
Ответить \| Правка \| Cообщить модератору

Оглавление

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., odus, 08:17 , 28-Фев-11, (1)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., анон, 10:48 , 28-Фев-11, (4) +2

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., pavlinux, 17:56 , 28-Фев-11, (14) +2

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., northbear, 20:31 , 28-Фев-11, (15) –1

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., pavlinux, 20:56 , 28-Фев-11, (17) +1

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., northbear, 06:05 , 01-Мрт-11, (21)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., DFX, 09:47 , 01-Мрт-11, (28)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., northbear, 15:49 , 01-Мрт-11, (30)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., DFX, 19:33 , 02-Мрт-11, (33)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., User294, 22:30 , 28-Фев-11, (20)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., northbear, 06:33 , 01-Мрт-11, (22)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., stalker37, 09:19 , 28-Фев-11, (2)
Проект по избавлению Linux-ядра от излишней сетевой буфериза..., Ромка, 12:30 , 28-Фев-11, (8)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., Аноним, 13:46 , 28-Фев-11, (11)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., Аноним, 13:50 , 28-Фев-11, (12)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., pavlinux, 17:34 , 28-Фев-11, (13)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., СуперАноним, 21:44 , 28-Фев-11, (18)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., User294, 22:22 , 28-Фев-11, (19)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., СуперАноним, 08:47 , 01-Мрт-11, (26)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., northbear, 07:00 , 01-Мрт-11, (23)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., К.О., 07:24 , 01-Мрт-11, (24)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., К.О., 07:26 , 01-Мрт-11, (25)
Проект по избавлению Linux-ядра от излишней сетевой буфериза..., northbear, 16:01 , 01-Мрт-11, (31)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., Andrey Mitrofanov, 18:21 , 01-Мрт-11, (32)
Проект по избавлению Linux-ядра от излишней сетевой буфериза..., К.О., 17:22 , 07-Мрт-11, (34)

Проект по избавлению Linux-ядра от излишней сетевой буфериза..., СуперАноним, 08:56 , 01-Мрт-11, (27)

Сообщения по теме [Сортировка по времени | RSS]

1. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от odus (ok) on 28-Фев-11, 08:17

Вообще выключили
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]

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +2 +/–

Сообщение от анон on 28-Фев-11, 10:48

>The TCP bandwidth delay product window limiting algorithm
Скажите, а как это относится к сабжу?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

14. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +2 +/–

Сообщение от pavlinux (ok) on 28-Фев-11, 17:56

А это BSD, у них всё через ж...у.
Вместо определения размера буфера, они определяют время задержки. :)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

15. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." –1 +/–

Сообщение от northbear (ok) on 28-Фев-11, 20:31

Да не... Это у тебя мозги оттуда растут.
Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста.

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +1 +/–

Сообщение от pavlinux (ok) on 28-Фев-11, 20:56

Ну конечно, и в независимости от трафика они все будут торчать в буфере 10 мс,
пофигу что, PPP, WiFi или 10G Ethernet. Получиться этакий Stable Ping.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от northbear (ok) on 01-Мрт-11, 06:05

Не тормози... Не более 10ms. На уровне TCP не имеет значения по какому транспорту поступают пакеты в роутер.
Если вдруг это действительно становится принципиальным, то для этого ставятся специализированные железки заточенные под обслуживание конкретного типа траффика.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

28. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от DFX (ok) on 01-Мрт-11, 09:47

ну нифигасебе, автор уже придумал какой-то свой 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...

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

30. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от northbear (??) on 01-Мрт-11, 15:49

Эмоционально... Про окно вы все верно сказали. Только при чем тут окно? 0_о
Прочитайте статью Transmission Control Protocol про flow control и congestion control. Вам будет понятно о чем говорится в новости.
Про память, еще раз... Меня не интересует размер буфера. Меня интересует время задержки. И если железо не может мне гарантировать в данном узле при данной нагрузке то время задержки которое я считаю приемлемым для себя, то такое железо мне просто не нужно.
Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.
Я знаю, что такое аппаратные буферы. К буферам о которых говорится в новости они не имеют никакого отношения.
Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть. Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах.
Я в свое время тоже этому удивился. Теперь же мне непонятно как может быть иначе. :)
еще раз... аппаратные буферы нерасширяемы, т.е. как только они переполняются, система вынуждена дропать пакеты. Удаленная сторона, видя, что пакеты теряются, сообщает отправителю, что надо снизить скорость передачи.
Когда память стала дешевой, кто-то решил, что программные автоматически расширяемые за счет оперативки буферы это круто. С одной стороны выглядит неплохо, пакеты не теряются, никаких ретрансмиссий нет. Но по итогу работа алгоритмов управления потоками и заторами TCP оказалась полностью нарушенной, о чем, собственно и говорится в новости.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

33. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от DFX (ok) on 02-Мрт-11, 19:33

>> Только при чем тут окно? 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'ах ?

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

20. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от User294 (ok) on 28-Фев-11, 22:30

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

22. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от northbear (ok) on 01-Мрт-11, 06:33

>> Для серьезных систем пох сколько памяти понадобится для буфера.
> А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание?
> Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то
> не попадались. Также не понятно зачем вообще буферизовать все и вся
> с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу?
> oO
Ты вообще серьезное железо видел? А документацию хоть раз пробовал почитать? Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить?
Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы. Сколько при этом система потратит памяти мне по барабану. Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины. Исходя из этого и подбирается железо.
Это и есть "Ынтерпрайзный" подход к делу.
А вы дома можете хоть в литрах буфера измерять. Только тип жидкости не забывайте указывать.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

2. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от stalker37 on 28-Фев-11, 09:19

Хех... ну что же посмотрим что из этого выйдет.. Есть где бы такое было интересно пощупать в продакшене.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от Ромка on 28-Фев-11, 12:30

А что такое сетевая буферизация? Нет, серьёзно. Впервые слышу. :-(

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от Аноним (??) on 28-Фев-11, 13:46

Гуглить в сторону "Network buffering". На русском я пока не нашел ничего...

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от Аноним (??) on 28-Фев-11, 13:50

Вот, например:
http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/...

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от pavlinux (ok) on 28-Фев-11, 17:34

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

18. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от СуперАноним on 28-Фев-11, 21:44

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от User294 (ok) on 28-Фев-11, 22:22

Добро пожаловать в реальный мир, мир tradeoff'ов и компромиссов :). В идеальном мире было бы круто передавать данные с входа на выход с нулевой задержкой и бесконечной скоростью. В реальном так, как вы понимаете, не катит - нас забыли снабдить процессорами бесконечной мощности с нулевым временем реакции на событие вида "получена порция данных" ака "прерывание", да и сети почему-то обладают хоть и приличной но конечной скоростью передачи данных :)

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от СуперАноним on 01-Мрт-11, 08:47

Ну так и я о том же ;)

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

23. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от northbear (ok) on 01-Мрт-11, 07:00

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от К.О. on 01-Мрт-11, 07:24

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

25. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от К.О. on 01-Мрт-11, 07:26

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

31. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от northbear (??) on 01-Мрт-11, 16:01

> Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без
> поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко
> тактов на сохранение основных регистров.
> В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение
> контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.
Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой подсистеме прерывания аппаратные.
Не очень хорошо понимаю, что значит уменьшить число прерываний? Если данные пришли, то их надо обрабатывать. Можно конечно попробовать игнорировать прерывания, но что сетевой карте тогда делать с вашими данными?
Может имеет смысл покупать адекватные сетевые карты которые имеют нормальный буфер?

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

32. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от Andrey Mitrofanov on 01-Мрт-11, 18:21

> Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой
> подсистеме прерывания аппаратные.
Иногда эффективнее поллить, говорят... Отключив прерывания, о ужас.
google:NAPI

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от К.О. on 07-Мрт-11, 17:22

Про поллинг что-нибудь слышали? Или про обработку нескольких пакетов в прерывание? А это - уже буферизация, и повышение latency.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

27. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..." +/–

Сообщение от СуперАноним on 01-Мрт-11, 08:56

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
Сообщение от odus (ok) on 28-Фев-11, 08:17
Вообще выключили 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]
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+2 +/–
	Сообщение от анон on 28-Фев-11, 10:48
	>The TCP bandwidth delay product window limiting algorithm Скажите, а как это относится к сабжу?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	14. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+2 +/–
	Сообщение от pavlinux (ok) on 28-Фев-11, 17:56
	А это BSD, у них всё через ж...у. Вместо определения размера буфера, они определяют время задержки. :)
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	15. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	–1 +/–
	Сообщение от northbear (ok) on 28-Фев-11, 20:31
	Да не... Это у тебя мозги оттуда растут. Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста. А вот время задержки при прохождении пакета через роутер, это вполне конкретный параметр и измеряется он никак не в мегабайтах.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	17. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+1 +/–
	Сообщение от pavlinux (ok) on 28-Фев-11, 20:56
	Ну конечно, и в независимости от трафика они все будут торчать в буфере 10 мс, пофигу что, PPP, WiFi или 10G Ethernet. Получиться этакий Stable Ping.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	21. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от northbear (ok) on 01-Мрт-11, 06:05
	Не тормози... Не более 10ms. На уровне TCP не имеет значения по какому транспорту поступают пакеты в роутер. Если вдруг это действительно становится принципиальным, то для этого ставятся специализированные железки заточенные под обслуживание конкретного типа траффика.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	28. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от DFX (ok) on 01-Мрт-11, 09:47
	ну нифигасебе, автор уже придумал какой-то свой 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...
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	30. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от northbear (??) on 01-Мрт-11, 15:49
	Эмоционально... Про окно вы все верно сказали. Только при чем тут окно? 0_о Прочитайте статью Transmission Control Protocol про flow control и congestion control. Вам будет понятно о чем говорится в новости. Про память, еще раз... Меня не интересует размер буфера. Меня интересует время задержки. И если железо не может мне гарантировать в данном узле при данной нагрузке то время задержки которое я считаю приемлемым для себя, то такое железо мне просто не нужно. Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов. Я знаю, что такое аппаратные буферы. К буферам о которых говорится в новости они не имеют никакого отношения. Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть. Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах. Я в свое время тоже этому удивился. Теперь же мне непонятно как может быть иначе. :) еще раз... аппаратные буферы нерасширяемы, т.е. как только они переполняются, система вынуждена дропать пакеты. Удаленная сторона, видя, что пакеты теряются, сообщает отправителю, что надо снизить скорость передачи. Когда память стала дешевой, кто-то решил, что программные автоматически расширяемые за счет оперативки буферы это круто. С одной стороны выглядит неплохо, пакеты не теряются, никаких ретрансмиссий нет. Но по итогу работа алгоритмов управления потоками и заторами TCP оказалась полностью нарушенной, о чем, собственно и говорится в новости.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	33. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от DFX (ok) on 02-Мрт-11, 19:33
	>> Только при чем тут окно? 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'ах ?
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	20. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от User294 (ok) on 28-Фев-11, 22:30
	> Для серьезных систем пох сколько памяти понадобится для буфера. А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание? Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то не попадались. Также не понятно зачем вообще буферизовать все и вся с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу? oO
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	22. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от northbear (ok) on 01-Мрт-11, 06:33
	>> Для серьезных систем пох сколько памяти понадобится для буфера. > А что система делает если памяти не хватит? Катастрофически подыхает? Заваливает обслуживание? > Срывает заявленный ToS? А то чипы памяти бесконечной емкости мне почему-то > не попадались. Также не понятно зачем вообще буферизовать все и вся > с поводом и без. Это такой серьезный, Ынтерпрайзный подход к делу? > oO Ты вообще серьезное железо видел? А документацию хоть раз пробовал почитать? Ты знаешь, например, почему производительность серьезных маршрутизаторов измеряется в pps? А что такое pps ты вообще знаешь? А как соотносится скорость портов, производительность в pps, максимально допустимое время задержки пакета и объем внутренней памяти для буфера можешь сообразить? Мне лично, да и любому профессионалу, важна пропускная способность и предел латентности системы. Сколько при этом система потратит памяти мне по барабану. Производитель конкретно указывает, что конкретная железка обеспечит указанное время обработки пакета при объеме траффика не более такой-то величины. Исходя из этого и подбирается железо. Это и есть "Ынтерпрайзный" подход к делу. А вы дома можете хоть в литрах буфера измерять. Только тип жидкости не забывайте указывать.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору

2. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
Сообщение от stalker37 on 28-Фев-11, 09:19
Хех... ну что же посмотрим что из этого выйдет.. Есть где бы такое было интересно пощупать в продакшене.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

8. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
Сообщение от Ромка on 28-Фев-11, 12:30
А что такое сетевая буферизация? Нет, серьёзно. Впервые слышу. :-(
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	11. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от Аноним (??) on 28-Фев-11, 13:46
	Гуглить в сторону "Network buffering". На русском я пока не нашел ничего...
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	12. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от Аноним (??) on 28-Фев-11, 13:50
	Вот, например: http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/...
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	13. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от pavlinux (ok) on 28-Фев-11, 17:34
	> А что такое сетевая буферизация? Очередь пакетов знаете? Так вот, этот дядька считает, что принудительное завышение размера очереди это нехорошо для сети.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору

18. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
Сообщение от СуперАноним on 28-Фев-11, 21:44
Вот только непонятно, как этот проект будет сочетаться с NAPI, который уменьшает частоту аппаратных прерываний от сетевых адаптеров именно за счёт буферизации нескольких последовательно принимаемых пакетов.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	19. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от User294 (ok) on 28-Фев-11, 22:22
	Добро пожаловать в реальный мир, мир tradeoff'ов и компромиссов :). В идеальном мире было бы круто передавать данные с входа на выход с нулевой задержкой и бесконечной скоростью. В реальном так, как вы понимаете, не катит - нас забыли снабдить процессорами бесконечной мощности с нулевым временем реакции на событие вида "получена порция данных" ака "прерывание", да и сети почему-то обладают хоть и приличной но конечной скоростью передачи данных :)
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	26. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от СуперАноним on 01-Мрт-11, 08:47
	Ну так и я о том же ;)
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	23. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от northbear (ok) on 01-Мрт-11, 07:00
	Полагаю, это вопрос возможностей. Ядро должно уметь обрабатывать траффик с минимальными задержками. А буферы включить принципиальных проблем нет, если вам это вдруг покажется необходимым. А что собственно вы имеете против прерываний? Они, эти самые прерывания, для того и создавались, чтобы обрабатывать события более важные, чем текущие задачи.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	24. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от К.О. on 01-Мрт-11, 07:24
	Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко тактов на сохранение основных регистров. В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору


	25. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от К.О. on 01-Мрт-11, 07:26
	> В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение > контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание. Ну и да, про аннулирование длиннющего префетча тоже молчу.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	31. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от northbear (??) on 01-Мрт-11, 16:01
	> Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без > поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко > тактов на сохранение основных регистров. > В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение > контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание. Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой подсистеме прерывания аппаратные. Не очень хорошо понимаю, что значит уменьшить число прерываний? Если данные пришли, то их надо обрабатывать. Можно конечно попробовать игнорировать прерывания, но что сетевой карте тогда делать с вашими данными? Может имеет смысл покупать адекватные сетевые карты которые имеют нормальный буфер?
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	32. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от Andrey Mitrofanov on 01-Мрт-11, 18:21
	> Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой > подсистеме прерывания аппаратные. Иногда эффективнее поллить, говорят... Отключив прерывания, о ужас. google:NAPI
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	34. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от К.О. on 07-Мрт-11, 17:22
	Про поллинг что-нибудь слышали? Или про обработку нескольких пакетов в прерывание? А это - уже буферизация, и повышение latency.
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	27. "Проект по избавлению Linux-ядра от излишней сетевой буфериза..."	+/–
	Сообщение от СуперАноним on 01-Мрт-11, 08:56
	>А что собственно вы имеете против прерываний? Если они происходят часто, то большой процент времени всяких там переключений аппаратных и программных. Поэтому, собственно, разрабатывашие NAPI и озаботились чтобы снизить частоту прерываний и за счёт этого увеличить пропускную способность сетевой подсистемы. И да, пропускная способность и латентность находятся в некотором антагонизме.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору