https://www.opennet.dev/openforum/vsluhforumID3/75037.html Анонсировано (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%29)). После проверки и стабилизации, обкатанные в ветке debloat-testing патчи будут направлены для включения в состав основного Linux-ядра.<br><br><br><br><br><br>Изначально термин Bufferbloat несколько месяцев назад предложил (http://gettys.wordpress.com/what-is-bufferbloat-anyway/) Джим Гетиc (Jim Gettys), член комитета W3C и разработчик спецификации HTTP/1.1, который в цикле статей (http://www.opennet.ru/opennews/art.shtml?num=29191) достато...<br><br>URL: https://lkml.o https://www.opennet.dev/openforum/vsluhforumID3/75037.html#34 Mon, 07 Mar 2011 14:22:05 GMT Про поллинг что-нибудь слышали? Или про обработку нескольких пакетов в прерывание? А это - уже буферизация, и повышение latency.<br> https://www.opennet.dev/openforum/vsluhforumID3/75037.html#33 Wed, 02 Mar 2011 16:33:07 GMT &gt;&gt; Только при чем тут окно? 0_о<br><br>то не про статьюж было, а про камент с "The TCP bandwidth delay product window limiting algorithm controlled by the sysctl(8) variable net.inet.tcp.inflight.enable"<br><br>&gt;&gt; Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.<br><br>о чём речь в каментах и была. про soft-router'ы на BSD, да и вообще ковыряние в сетевой подсистеме BSD и Linux<br><br>&gt;&gt; Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиональных систем именно так и должно быть.<br><br>в этом конкретном случае размер буфера похоже не тольк не настраивался, но и не учитывался алгоритмом вообще.<br><br>&gt;&gt; Пример, jitter-буфер в VoIP-шлюзах Cisco тоже измеряется в миллисекундах. <br><br>ммм, ничего про это не знаю, https://www.opennet.dev/openforum/vsluhforumID3/75037.html#32 Tue, 01 Mar 2011 15:21:54 GMT &gt; Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой <br>&gt; подсистеме прерывания аппаратные.<br><br>Иногда эффективнее поллить, говорят... Отключив прерывания, о ужас.<br><br>google:NAPI<br> https://www.opennet.dev/openforum/vsluhforumID3/75037.html#31 Tue, 01 Mar 2011 13:01:27 GMT &gt; Ничего, если у Вас Z80, MIPS или что-то иное с RTOS без <br>&gt; поддержки многозадачности. Тогда прерывание - это фактически просто JMP + немножечко <br>&gt; тактов на сохранение основных регистров.<br>&gt; В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение <br>&gt; контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание. <br><br>Одно но... Вы знаете какой-то другой способ работать с железом? В сетевой подсистеме прерывания аппаратные. <br><br>Не очень хорошо понимаю, что значит уменьшить число прерываний? Если данные пришли, то их надо обрабатывать. Можно конечно попробовать игнорировать прерывания, но что сетевой карте тогда делать с вашими данными? <br><br>Может имеет смысл покупать адекватные сетевые карты которые имеют нормальный буфер? <br> https://www.opennet.dev/openforum/vsluhforumID3/75037.html#30 Tue, 01 Mar 2011 12:49:37 GMT Эмоционально... Про окно вы все верно сказали. Только при чем тут окно? 0_о<br>Прочитайте статью Transmission Control Protocol про flow control и congestion control. Вам будет понятно о чем говорится в новости. <br><br>Про память, еще раз... Меня не интересует размер буфера. Меня интересует время задержки. И если железо не может мне гарантировать в данном узле при данной нагрузке то время задержки которое я считаю приемлемым для себя, то такое железо мне просто не нужно. <br>Проблема шлюзов на базе PC и Linux'а как раз в этом и состоит, что для того, чтобы хоть как-то управлять (или хотя бы измерить) уровнем латентности системы, нужны совершенно нетривиальные пляски с бубном и не зная потрохов ядра, вряд ли это можно добиться сколь-либо интересных результатов.<br><br>Я знаю, что такое аппаратные буферы. К буферам о которых говорится в новости они не имеют никакого отношения. <br>Речь о том, что pavlinux поиронизировал по поводу того, что размер буфера в BSD-системах определяется в ms. на что я и указал, что для профессиона https://www.opennet.dev/openforum/vsluhforumID3/75037.html#28 Tue, 01 Mar 2011 06:47:20 GMT ну нифигасебе, автор уже придумал какой-то свой TCP, с буферастыми маршрутизаторами и их преферансами в L4 ?<br><br>а ничего, что результат перемножения пропускной_способности_канала(порта) на задержку(Round Trip Time), основополагающая величина для исчисления окна TCP ?<br>http://en.wikipedia.org/wiki/Bandwidth-delay_product<br>"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."<br><br>&gt;&gt; Для серьезных систем пох сколько памяти понадобится для буфера. При нынешней ее стоимости это может интересовать только чайников или бедолаг убогом железе, но никак не специалиста. <br><br>вот про таких в статье и написано... цена падает -&gt; доступные размеры памяти растут быстро, скорость работы этой памяти https://www.opennet.dev/openforum/vsluhforumID3/75037.html#27 Tue, 01 Mar 2011 05:56:45 GMT &gt;А что собственно вы имеете против прерываний?<br><br>Если они происходят часто, то большой процент времени всяких там переключений аппаратных и программных. Поэтому, собственно, разрабатывашие NAPI и озаботились чтобы снизить частоту прерываний и за счёт этого увеличить пропускную способность сетевой подсистемы. И да, пропускная способность и латентность находятся в некотором антагонизме.<br> https://www.opennet.dev/openforum/vsluhforumID3/75037.html#26 Tue, 01 Mar 2011 05:47:20 GMT Ну так и я о том же ;)<br> https://www.opennet.dev/openforum/vsluhforumID3/75037.html#25 Tue, 01 Mar 2011 04:26:18 GMT &gt; В x86 PM/LM прерывание - это _двойное_ (на вход и выход) переключение <br>&gt; контекста, фигова уйма тактов. Ну и плюс естественные накладные на обслуживание. <br><br>Ну и да, про аннулирование длиннющего префетча тоже молчу.<br>