Компания Google опубликовала (https://patchwork.ozlabs.org/patch/671069/) патчи для сетевой подсистемы ядра Linux с реализацией нового алгоритма контроля перегрузки TCP (congestion control) - BBR (Bottleneck Bandwidth and RTT). Внедрение BBR во внутренней сети Google позволило значительно увеличить пропускную способность и сократить задержки передачи данных для трафика с google.com и
YouTube. BBR требует внесения изменений только на стороне отправителя, программное обеспечение сетевой инфраструктуры и принимающей стороны остаётся без изменений.
В отличие от классических алгоритмов Reno и CUBIC, использующих потерю пакетов в качестве индикатора перегрузки, в BBR применяются методы моделирования канала связи, прогнозирующие имеющуюся пропускную способность через последовательные проверки и оценку времени приема-передачи (RTT), но не доводя до потери пакетов.URL: https://patchwork.ozlabs.org/patch/671069/
Новость: https://www.opennet.ru/opennews/art.shtml?num=45167
Чем лучше Remy? https://www.opennet.ru/opennews/art.shtml?num=37482Локальная сеть google это вам не WAN с кучей вредителей которые только и ждут использовать больно умные алгоритмы для повышения аттаки.
Тем что BBR это патч для линукса, который можно скомпилить и включить, а Remy это исследовательский прототип, который полюбому тормозит или вообще работает не в реалтайме, а в симуляторе.
>Локальная сеть google это вам не WANВот вот. Взять их оптику в нищих районах пендосии, кэш-серверы ютьюба у ВСЕХ крупных провайдеров, слегка принять во внимание инфраструктуру дата-центров и возвести в квадрат. Как-то так можно оценить их WAN. А в остальном, прекрасная маркиза, все хорошо, все хорошо.
> Локальная сеть google это вам не WAN с кучей вредителейУ гугля локальной сетью с их ютубом - вся планета. И тут то как раз оказывается что существующие существующие алгоритмы работают с всякими wi-fi и 4G просто никак.
Например в беспроводных сетях некоторое выпадение пакеров - обычное явление и может быть следствием помех, движения или просто попыткой прокачать больше чем физический уровень может обеспечить, от чего все эти рено и кубики плющит. Они начинают осциллировать (!!!) и постепенно загоняют себя в режим когда данные почти не идут вообще. Скорость прокачки становится спасибо если треть возможностей канала.
> больно умные алгоритмы для повышения аттаки.
Кубики и рено в беспроводных сетях сами себя DoS'ят. Что гуглу не нравится - у пользователей ютуб икает. Единственный кто всерьез это учитывает из существующих - CDG (caia delay gradient) который использует чем-то похожие подходы и с недавних пор включен в ядро Linux. С ним по беспроводке скорость может быть куда лучше. Но гугл видимо нашел фатальный недостаток: cdg придумали не они.
Им стоило бы начать с объяснения чем не устроил Illinois, кроме того что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?
> Им стоило бы начать с объяснения чем не устроил Illinois, кроме того
> что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?По беспроводным сетям из того что в Linux есть сколь-нибудь вменяемо работает разве что cdg. Который есть только в паре свежих версий ядер Linux.
Упомянутый алгоритм чем-то напоминает подходы cdg, но немного с другой стороны.
Бибер?
Кубик и рено не лучшие, оно и не удивительно.
Но есть htcp, hybla которые в локалках весьма работают, да и в диком инете тоже.
Тестов что то не видать.
>Кубик и рено не лучшие, оно и не удивительно.Неудивительно. Ведь они придуманы в эпоху проводных сетей с последующей адаптацией к реалиям.
https://habrahabr.ru/post/168407/
///---
К сожалению, CUBIC, который используется по умолчанию во всех дистрибутивах, совершенно не подходит, например, для 3G-соединений.
<...>
Как видите, CUBIC в отстающих. Он значительно повысил RTT на полной утилизации 3G канала, в то время как Westwood+ и NewReno более-менее справляются с этой проблемой.
<...>
Как видно из графика, у CUBIC относительно большое количество ретрансмиссий
<...>
В то же время, он лидирует в скорости передачи данных за единицу времени.Что это значит? Это значит, что с использованием Westwood+ или NewReno вы сможете комфортней серфить интернет, пока у вас скачивается большой файл.
---///
Поэтому в Linux рулит CDG. А что рулит в bsd? Или их еще не отпустило?
> Поэтому в Linux рулит CDG. А что рулит в bsd?Во Фре NewReno по умолчанию.
А так:
/boot/kernel/cc_cdg.ko
/boot/kernel/cc_chd.ko
/boot/kernel/cc_hd.ko
/boot/kernel/cc_htcp.ko
/boot/kernel/cc_cubic.ko
/boot/kernel/cc_dctcp.ko
/boot/kernel/cc_vegas.ko
Что загрузишь - то и будет.> Или их еще не отпустило?
В смысле?
Этот NewReno - как и в линуксах докостыленный вариант reno? :) Хз как в бсд но в линуксах тамошний пиленый-перепиленый рено не сильно дружит с беспроводкой. CDG интересен тем что рассматривает delay gradient как критерий перегрузки. Потери пакетов его не очень смущают, ему рост RTT важенее и это куда более удачный критерий на беспроводке. На неидеальном беспроводном канале это работает лучше. На остальных каналах это тоже вполне адекватный критерий как правило. Сабж судя по описанию чем-то похож, он тоже не считает потери пакетов главным критерием для понижения скорости. А всякие reno/vegas и подобные по смыслу из-за излишнего упования на потери пакетов как критерий душат скорость соединения на ровном месте, а то и вовсе коллапсируют.
Болт на них - ламеры :)
Я сам для себя тестил в немного других условиях:
RTT > 70
потери пакетов
При этом мне нужен был поток стабильный в 4-10 мегабит - смотрел IPTV через пол страны: Иркутск-Москва.Короче: всё говно кроме hybla и htcp, притом последний тоже не очень то работал.
hybla - единственно с чем поток был стабильный и просмотр без залипаний.
htcp - он лучше hybla когда RTT по меньше и потерь меньше, особенно это заметно в локалках.И вывод них тоже идиотский, ведь важно какой СС на сервере а не у тебя, потому что сёрфинг+скачивание - это всё получение данных с сервера.
Как включить нужный алгоритм Congestion Control TCP во FreeBSD1. Что имеем в текущий момент:
% sysctl net.inet.tcp.cc.algorithm
net.inet.tcp.cc.algorithm: newreno% sysctl net.inet.tcp.cc.available
net.inet.tcp.cc.available: newreno2. Смотрим, какие модули нам доступны:
% ls /boot/kernel/cc_*
/boot/kernel/cc_cdg.ko /boot/kernel/cc_hd.ko
/boot/kernel/cc_chd.ko /boot/kernel/cc_htcp.ko
/boot/kernel/cc_cubic.ko /boot/kernel/cc_vegas.ko
/boot/kernel/cc_dctcp.ko(FreeBSD 11.0-PRERELEASE)
3. Выбираем алгоритм, например, Vegas.
3.1. Загружаем нужный модуль:
% kldload cc_vegas
Проверяем:
% sysctl net.inet.tcp.cc.available
net.inet.tcp.cc.available: newreno, vegas3.2. Переключаемся на него:
% sysctl net.inet.tcp.cc.algorithm=vegas
net.inet.tcp.cc.algorithm: newreno -> vegasПроверяем:
% sysctl net.inet.tcp.cc.algorithm
net.inet.tcp.cc.algorithm: vegasИспытываем радость или печаль - в зависимости от предъявляемых требований и удовлетворения ожиданий.
Это ты мне рассказываешь?)))У меня мой msd/msd_lite умеет выставлять алгоритмы на сокеты.
Те можно на соединения принимаемые с биндиного сокета на 192.168.0.1 выставлять htcp,
а на соединения принимаемые с сокета прибинденого на 172.16.0.1 ставить скажем vegas (чтобы они страдали :) ).И потом у меня лежит hybla для фри, сам портировал...
Но у фри там что то сломано относительно линуха, потому что я тестил htcp который есть и там и там и фря у меня сливала 3-5 раз по скорости.
А CDG не пробовали на FreeBSD 11.1-BETA2?
>>> BBR оценивает потолок пропускной способности каналанепонял я что эти горбы под 1000Мгб/s в Заббиксе наблюдать должен ?
10G 40G 100G
Эта технология хороша только для 100% загруженных каналов, где ориентироваться постоянно только на потери, это значит иметь постоянно проблемы с потерями. Там эта технология выглядит логичной и полезной.
Если канал не имеет потерь и не загружен на 100% то и планировщик ему не требуется по большому счету - что так пакеты можно немедленно слать что эдак. Проблемы начинаются когда эта идилия нарушается. И совсем не круто если то RTT уходит в небеса, то кач со скоростью 30% канала.
В таких 100% загруженных сетях вы будете на графиках видеть только "горбы" пропавших пакетов. А с этой технологией как-раз всё будет тихо-мирно ;)