https://opennet.me/openforum/vsluhforumID3/82815.html Джим Гетиc (Jim Gettys), член комитета W3C, разработчик спецификации HTTP/1.1 и автор первой реализации системы X Window, подготовил (https://gettys.wordpress.com/2012/02/01/bufferbloat-demonstration-videos/) видеоролик с пояснением причин возникновения эффекта "Bufferbloat (http://www.bufferbloat.net/)" и способов борьбы с ним. Под Bufferbloat понимается феномен негативного влияния промежуточной буферизации пакетов на пропускную способность, однородность потока (jitter (http://en.wikipedia.org/wiki/Packet_delay_variation)) и время прохождения пакетов (latency (http://en.wikipedia.org/wiki/Latency_%28engineering%29)). На практике, предложенные в рамках проекта Bufferbloat методы решения проблем, возникающих из-за излишней буферизации, можно опробовать, воспользовавшись дистрибутивом CeroWrt (http://www.bufferbloat.net/projects/cerowrt). В рамках CeroWrt развивается прошивка для беспроводных точек доступа и маршрутизаторов, базирующаяся на наработках OpenWRT и нацеленная на решение насу...<br><br>URL: https://gettys https://opennet.me/openforum/vsluhforumID3/82815.html#23 Wed, 08 Feb 2012 08:20:04 GMT OK, теория есть, но никакой информации по сравнению в каких-то реальных условиях или примеров, чем одно лучше другого нет. Превосходство обоих над более базовыми алгоритмами вроде как понятно, но это все, что можно оттуда извлечь.<br> https://opennet.me/openforum/vsluhforumID3/82815.html#22 Wed, 08 Feb 2012 04:56:32 GMT http://book.itep.ru/4/44/tcp.htm<br> https://opennet.me/openforum/vsluhforumID3/82815.html#21 Tue, 07 Feb 2012 12:37:18 GMT А где почитать внятное объяснение, чем он лучше cubic? Желательно с каким-нибудь реальным примером или бенчмарком..<br> https://opennet.me/openforum/vsluhforumID3/82815.html#20 Tue, 07 Feb 2012 11:24:35 GMT &gt; Поэтому я и спрашиваю - а на полноценных системах, где я готов <br>&gt; сам сделать твики, а не ждать, пока дядя выкатит новый бинарник <br>&gt; фирмвари - что конкретно делать-то? Это же не секрет, надеюсь?<br><br>Та же OpenWRT - вполне полноценная система, ВНЕЗАПНО. То что она использует не х86 - ну и что? Какой даун придумал что компьютер - обязательно х86 и с механическим диском? <br> https://opennet.me/openforum/vsluhforumID3/82815.html#19 Tue, 07 Feb 2012 10:30:52 GMT sysctl -w net.ipv4.tcp_congestion_control=veno<br> https://opennet.me/openforum/vsluhforumID3/82815.html#18 Tue, 07 Feb 2012 01:17:29 GMT Линь такой же, но про них в новости упомянули - типа, будет модификация OpenWRT, где эти твики сделаны. Готовый бинарник с кнопочкой "download" для энд-юзеров, которые не хотят мучаться с твиками коробочки.<br><br>Поэтому я и спрашиваю - а на полноценных системах, где я готов сам сделать твики, а не ждать, пока дядя выкатит новый бинарник фирмвари - что конкретно делать-то? Это же не секрет, надеюсь?<br><br>ЗЫ кстати вот еще, непонятно - по-моему все практические примеры от этого чувака почти всегда идут с использованием 802.11; какая часть этих проблем *вообще* касается проводных интерфейсов? Или речь постоянно идет про буферы при использовании беспроводных интерфейсов? Последнее объяснило бы, почему так рьяно все время говорят про проблемы на коробочках, про прошивки для них и т.д., и не упоминают про твики для роутеров вообще, где все интерфейсы проводные.<br> https://opennet.me/openforum/vsluhforumID3/82815.html#17 Mon, 06 Feb 2012 22:35:48 GMT &gt; Потому что трафф или лезет в канал или нет. Ждать полчаса чтобы обломаться - хуже чем обломаться сразу.<br><br>Давайте будем различать кэш и буфер. И не будем приводить их как аналогии :)<br> https://opennet.me/openforum/vsluhforumID3/82815.html#16 Mon, 06 Feb 2012 20:18:34 GMT смысл в том, что произошло разделение уровней абстракций головного мозга в стеке (примерно как в модели OSI), т.е. алгоритм перегрузки не знает что есть буфер, а буфер не знает что есть алгоритм перегрузки. Вот и вся пичаль... нет, сейчас опять кинет людей в крайности, будут искать козла отпущения в буферизации.<br> https://opennet.me/openforum/vsluhforumID3/82815.html#15 Mon, 06 Feb 2012 18:04:00 GMT Это как с бабами - не дала, засунул другой. :) <br><br>---<br><br>Тока бутылкино горлышко тут не в буферах, а алгоритме согласования, <br>ибо нефига занижать скорость, если последнем пришедшем TCP пакете <br>есть параметр NEXT_FRAME (Next Expected Sequence) (то есть данные ещё будут).<br>и наконец впиндюрить алгоритм предсказывания - вот к примеру шли данные <br>2000 мс, затем 250 мс таймаут, и так далее: 2000-250, 2000-250,2000-250,2000-250,2000-XXX<br>угадайте чему и с какой вероятностью будет равно XXX ?<br><br>---<br><br>Неделю назад Гугля кричала, что мало данных суём в канал, надо собрать <br>не менее 10 пакетов, и только тогда сбрасывать!!! Кстати тоже вариант <br>решения против простоя. <br><br><br><br> <br>