Джим Гетиc (Jim Gettys), член комитета W3C, разработчик спецификации HTTP/1.1 и автор первой реализации системы X Window, подготовил (https://gettys.wordpress.com/2012/02/01/bufferbloat-demonstr... видеоролик с пояснением причин возникновения эффекта "Bufferbloat (http://www.bufferbloat.net/)" и способов борьбы с ним. Под Bufferbloat понимается феномен негативного влияния промежуточной буферизации пакетов на пропускную способность, однородность потока (jitter (http://en.wikipedia.org/wiki/Packet_delay_variation)) и время прохождения пакетов (latency (http://en.wikipedia.org/wiki/Latency_%28engineering.... На практике, предложенные в рамках проекта Bufferbloat методы решения проблем, возникающих из-за излишней буферизации, можно опробовать, воспользовавшись дистрибутивом CeroWrt (http://www.bufferbloat.net/projects/cerowrt). В рамках CeroWrt развивается прошивка для беспроводных точек доступа и маршрутизаторов, базирующаяся на наработках OpenWRT и нацеленная на решение насу...URL: https://gettys.wordpress.com/2012/02/01/bufferbloat-demonstr.../
Новость: http://www.opennet.me/opennews/art.shtml?num=33006
Не с целью проведения опасных аналогий, до которых тут же докопаются местные иксперты, но справедливости для - избыточное кэширование вызывает давно известный тюнерам негативный эффект подобного плана.Не удивили.
Вам хотели сказать, что промежуточный узел неуспеваючий отправить пакет, должен его дропать, а не отправлять в буфер отправки--- это далеко не очевидное решение. Смысл в том, что наличие таких буферов сбивает с толку алгоритмы маршрутизации.
Спасибо, дислексией не страдаю. Я прекрасно понял, что хотели сказать МНЕ.Как бывший тюнер, могу заметить - и провести ту самую параллель - что попытки устранять узкие места, заливая их гигабайтами RAM - всегда было проигрышной политикой.
> Как бывший тюнер, могу заметить - и провести ту самую параллель - что попытки устранять узкие места, заливая их гигабайтами RAM - всегда было проигрышной политикой.При относительно предсказуемых IO операциях с медленным носителем - пуркуа бы и не па?
> При относительно предсказуемых IO операциях с медленным носителем - пуркуа бы и не па?Потому что трафф или лезет в канал или нет. Ждать полчаса чтобы обломаться - хуже чем обломаться сразу.
Это как с бабами - не дала, засунул другой. :)---
Тока бутылкино горлышко тут не в буферах, а алгоритме согласования,
ибо нефига занижать скорость, если последнем пришедшем TCP пакете
есть параметр NEXT_FRAME (Next Expected Sequence) (то есть данные ещё будут).
и наконец впиндюрить алгоритм предсказывания - вот к примеру шли данные
2000 мс, затем 250 мс таймаут, и так далее: 2000-250, 2000-250,2000-250,2000-250,2000-XXX
угадайте чему и с какой вероятностью будет равно XXX ?---
Неделю назад Гугля кричала, что мало данных суём в канал, надо собрать
не менее 10 пакетов, и только тогда сбрасывать!!! Кстати тоже вариант
решения против простоя.
> Потому что трафф или лезет в канал или нет. Ждать полчаса чтобы обломаться - хуже чем обломаться сразу.Давайте будем различать кэш и буфер. И не будем приводить их как аналогии :)
смысл в том, что произошло разделение уровней абстракций головного мозга в стеке (примерно как в модели OSI), т.е. алгоритм перегрузки не знает что есть буфер, а буфер не знает что есть алгоритм перегрузки. Вот и вся пичаль... нет, сейчас опять кинет людей в крайности, будут искать козла отпущения в буферизации.
Где конкретные советы по поводу того, как тюнить *правильно*? Если роутером у меня обычный линуксовый сервер, а не коробочка.
С точки зрения Интернета проблема глобальна, и должна держаться под контролем всеми.
Ну что с того, если ты отключишь буфера _вообще_ на своём роутере, если десяток следующих хопов этого не сделает?-)
Ну так надо же с чего-то начинать?
> Если роутером у меня обычный линуксовый сервер, а не коробочка.Можно подумать в коробочках линь какой-то другой, ага.
Ну тот же, а толку? Если он под замком, а для юзера "ковырялку гламурную" сделали через httpd
> Ну тот же, а толку? Если он под замком, а для юзера
> "ковырялку гламурную" сделали через httpdПользуйся нормальными прошивками - будет без замка.
>> Ну тот же, а толку? Если он под замком, а для юзера
>> "ковырялку гламурную" сделали через httpd
> Пользуйся нормальными прошивками - будет без замка.Ну сопсна.. WRT и спасает, пока что..
Думаю про него и была речь изначально. (про отличае от обычных коробочек)
> Ну сопсна.. WRT и спасает, пока что..
> Думаю про него и была речь изначально. (про отличае от обычных коробочек)Ну так вон перцы на ее основе и сгородили тулсень для сетевых экспериментов. Чем оно и хорошо :)
Линь такой же, но про них в новости упомянули - типа, будет модификация OpenWRT, где эти твики сделаны. Готовый бинарник с кнопочкой "download" для энд-юзеров, которые не хотят мучаться с твиками коробочки.Поэтому я и спрашиваю - а на полноценных системах, где я готов сам сделать твики, а не ждать, пока дядя выкатит новый бинарник фирмвари - что конкретно делать-то? Это же не секрет, надеюсь?
ЗЫ кстати вот еще, непонятно - по-моему все практические примеры от этого чувака почти всегда идут с использованием 802.11; какая часть этих проблем *вообще* касается проводных интерфейсов? Или речь постоянно идет про буферы при использовании беспроводных интерфейсов? Последнее объяснило бы, почему так рьяно все время говорят про проблемы на коробочках, про прошивки для них и т.д., и не упоминают про твики для роутеров вообще, где все интерфейсы проводные.
> Поэтому я и спрашиваю - а на полноценных системах, где я готов
> сам сделать твики, а не ждать, пока дядя выкатит новый бинарник
> фирмвари - что конкретно делать-то? Это же не секрет, надеюсь?Та же OpenWRT - вполне полноценная система, ВНЕЗАПНО. То что она использует не х86 - ну и что? Какой даун придумал что компьютер - обязательно х86 и с механическим диском?
> Где конкретные советы по поводу того, как тюнить *правильно*? Если роутером у
> меня обычный линуксовый сервер, а не коробочка.Ждите, пока патчи от борцов с bufferbloat интегрируют в мейнстрим. Сохраняйте спокойствие.
sysctl -w net.ipv4.tcp_congestion_control=veno
А где почитать внятное объяснение, чем он лучше cubic? Желательно с каким-нибудь реальным примером или бенчмарком..
http://book.itep.ru/4/44/tcp.htm
OK, теория есть, но никакой информации по сравнению в каких-то реальных условиях или примеров, чем одно лучше другого нет. Превосходство обоих над более базовыми алгоритмами вроде как понятно, но это все, что можно оттуда извлечь.