форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

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

"Google опубликовал BBR, новый алгоритм контроля перегрузки TCP"	+/–
Сообщение от opennews (??) on 17-Сен-16, 23:42
Компания 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/ Новость: http://www.opennet.me/opennews/art.shtml?num=45167
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	–1 +/–
Сообщение от Аноним (??) on 17-Сен-16, 23:42
Чем лучше Remy? https://www.opennet.me/opennews/art.shtml?num=37482 Локальная сеть google это вам не WAN с кучей вредителей которые только и ждут использовать больно умные алгоритмы для повышения аттаки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+9 +/–
	Сообщение от Специалист по всему on 18-Сен-16, 00:28
	Тем что BBR это патч для линукса, который можно скомпилить и включить, а Remy это исследовательский прототип, который полюбому тормозит или вообще работает не в реалтайме, а в симуляторе.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+3 +/–
	Сообщение от kleemhead on 18-Сен-16, 03:03
	>Локальная сеть google это вам не WAN Вот вот. Взять их оптику в нищих районах пендосии, кэш-серверы ютьюба у ВСЕХ крупных провайдеров, слегка принять во внимание инфраструктуру дата-центров и возвести в квадрат. Как-то так можно оценить их WAN. А в остальном, прекрасная маркиза, все хорошо, все хорошо.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+2 +/–
	Сообщение от Аноним (??) on 18-Сен-16, 18:05
	> Локальная сеть google это вам не WAN с кучей вредителей У гугля локальной сетью с их ютубом - вся планета. И тут то как раз оказывается что существующие существующие алгоритмы работают с всякими wi-fi и 4G просто никак. Например в беспроводных сетях некоторое выпадение пакеров - обычное явление и может быть следствием помех, движения или просто попыткой прокачать больше чем физический уровень может обеспечить, от чего все эти рено и кубики плющит. Они начинают осциллировать (!!!) и постепенно загоняют себя в режим когда данные почти не идут вообще. Скорость прокачки становится спасибо если треть возможностей канала. > больно умные алгоритмы для повышения аттаки. Кубики и рено в беспроводных сетях сами себя DoS'ят. Что гуглу не нравится - у пользователей ютуб икает. Единственный кто всерьез это учитывает из существующих - CDG (caia delay gradient) который использует чем-то похожие подходы и с недавних пор включен в ядро Linux. С ним по беспроводке скорость может быть куда лучше. Но гугл видимо нашел фатальный недостаток: cdg придумали не они.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
Сообщение от rm_ (ok) on 18-Сен-16, 12:25
Им стоило бы начать с объяснения чем не устроил Illinois, кроме того что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+1 +/–
	Сообщение от Аноним (??) on 18-Сен-16, 18:17
	> Им стоило бы начать с объяснения чем не устроил Illinois, кроме того > что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика? По беспроводным сетям из того что в Linux есть сколь-нибудь вменяемо работает разве что cdg. Который есть только в паре свежих версий ядер Linux. Упомянутый алгоритм чем-то напоминает подходы cdg, но немного с другой стороны.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
Сообщение от Baz on 18-Сен-16, 12:31
Бибер?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
Сообщение от Ivan_83 (ok) on 18-Сен-16, 14:51
Кубик и рено не лучшие, оно и не удивительно. Но есть htcp, hybla которые в локалках весьма работают, да и в диком инете тоже. Тестов что то не видать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от iZEN (ok) on 19-Сен-16, 00:37
	>Кубик и рено не лучшие, оно и не удивительно. Неудивительно. Ведь они придуманы в эпоху проводных сетей с последующей адаптацией к реалиям. https://habrahabr.ru/post/168407/ ///--- К сожалению, CUBIC, который используется по умолчанию во всех дистрибутивах, совершенно не подходит, например, для 3G-соединений. <...> Как видите, CUBIC в отстающих. Он значительно повысил RTT на полной утилизации 3G канала, в то время как Westwood+ и NewReno более-менее справляются с этой проблемой. <...> Как видно из графика, у CUBIC относительно большое количество ретрансмиссий <...> В то же время, он лидирует в скорости передачи данных за единицу времени. Что это значит? Это значит, что с использованием Westwood+ или NewReno вы сможете комфортней серфить интернет, пока у вас скачивается большой файл. ---///
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	13. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от Аноним (??) on 19-Сен-16, 20:13
	Поэтому в Linux рулит CDG. А что рулит в bsd? Или их еще не отпустило?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от iZEN (ok) on 19-Сен-16, 20:52
	> Поэтому в 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 Что загрузишь - то и будет. > Или их еще не отпустило? В смысле?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	17. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от Аноним (??) on 20-Сен-16, 19:41
	Этот NewReno - как и в линуксах докостыленный вариант reno? :) Хз как в бсд но в линуксах тамошний пиленый-перепиленый рено не сильно дружит с беспроводкой. CDG интересен тем что рассматривает delay gradient как критерий перегрузки. Потери пакетов его не очень смущают, ему рост RTT важенее и это куда более удачный критерий на беспроводке. На неидеальном беспроводном канале это работает лучше. На остальных каналах это тоже вполне адекватный критерий как правило. Сабж судя по описанию чем-то похож, он тоже не считает потери пакетов главным критерием для понижения скорости. А всякие reno/vegas и подобные по смыслу из-за излишнего упования на потери пакетов как критерий душат скорость соединения на ровном месте, а то и вовсе коллапсируют.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от Ivan_83 (ok) on 20-Сен-16, 20:15
	Болт на них - ламеры :) Я сам для себя тестил в немного других условиях: RTT > 70 потери пакетов При этом мне нужен был поток стабильный в 4-10 мегабит - смотрел IPTV через пол страны: Иркутск-Москва. Короче: всё говно кроме hybla и htcp, притом последний тоже не очень то работал. hybla - единственно с чем поток был стабильный и просмотр без залипаний. htcp - он лучше hybla когда RTT по меньше и потерь меньше, особенно это заметно в локалках. И вывод них тоже идиотский, ведь важно какой СС на сервере а не у тебя, потому что сёрфинг+скачивание - это всё получение данных с сервера.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

10. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
Сообщение от iZEN (ok) on 19-Сен-16, 00:57
Как включить нужный алгоритм Congestion Control TCP во FreeBSD 1. Что имеем в текущий момент: % sysctl net.inet.tcp.cc.algorithm net.inet.tcp.cc.algorithm: newreno % sysctl net.inet.tcp.cc.available net.inet.tcp.cc.available: newreno 2. Смотрим, какие модули нам доступны: % 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, vegas 3.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 Испытываем радость или печаль - в зависимости от предъявляемых требований и удовлетворения ожиданий.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от Ivan_83 (ok) on 20-Сен-16, 20:20
	Это ты мне рассказываешь?))) У меня мой msd/msd_lite умеет выставлять алгоритмы на сокеты. Те можно на соединения принимаемые с биндиного сокета на 192.168.0.1 выставлять htcp, а на соединения принимаемые с сокета прибинденого на 172.16.0.1 ставить скажем vegas (чтобы они страдали :) ). И потом у меня лежит hybla для фри, сам портировал... Но у фри там что то сломано относительно линуха, потому что я тестил htcp который есть и там и там и фря у меня сливала 3-5 раз по скорости.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	21. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от iZEN (ok) on 20-Июн-17, 20:10
	А CDG не пробовали на FreeBSD 11.1-BETA2?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

11. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
Сообщение от AS (??) on 19-Сен-16, 18:41
>>> BBR оценивает потолок пропускной способности канала непонял я что эти горбы под 1000Мгб/s в Заббиксе наблюдать должен ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от Аноним (??) on 19-Сен-16, 19:03
	10G 40G 100G
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от mumu (??) on 19-Сен-16, 20:29
	Эта технология хороша только для 100% загруженных каналов, где ориентироваться постоянно только на потери, это значит иметь постоянно проблемы с потерями. Там эта технология выглядит логичной и полезной.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	18. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от Аноним (??) on 20-Сен-16, 19:43
	Если канал не имеет потерь и не загружен на 100% то и планировщик ему не требуется по большому счету - что так пакеты можно немедленно слать что эдак. Проблемы начинаются когда эта идилия нарушается. И совсем не круто если то RTT уходит в небеса, то кач со скоростью 30% канала.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	15. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."	+/–
	Сообщение от mumu (??) on 19-Сен-16, 20:31
	В таких 100% загруженных сетях вы будете на графиках видеть только "горбы" пропавших пакетов. А с этой технологией как-раз всё будет тихо-мирно ;)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

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

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