The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Google опубликовал BBR, новый алгоритм контроля перегрузки TCP"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"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.dev/opennews/art.shtml?num=45167

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."  –1 +/
Сообщение от Аноним (??) on 17-Сен-16, 23:42 
Чем лучше Remy? https://www.opennet.dev/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_ email(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 email(ok) on 18-Сен-16, 14:51 
Кубик и рено не лучшие, оно и не удивительно.
Но есть htcp, hybla которые в локалках весьма работают, да и в диком инете тоже.
Тестов что то не видать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."  +/
Сообщение от iZEN email(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 email(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 email(ok) on 20-Сен-16, 20:15 
Болт на них - ламеры :)
Я сам для себя тестил в немного других условиях:
RTT > 70
потери пакетов
При этом мне нужен был поток стабильный в 4-10 мегабит - смотрел IPTV через пол страны: Иркутск-Москва.

Короче: всё говно кроме hybla и htcp, притом последний тоже не очень то работал.
hybla - единственно с чем поток был стабильный и просмотр без залипаний.
htcp - он лучше hybla когда RTT по меньше и потерь меньше, особенно это заметно в локалках.

И вывод них тоже идиотский, ведь важно какой СС на сервере а не у тебя, потому что сёрфинг+скачивание - это всё получение данных с сервера.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

10. "Google опубликовал BBR, новый алгоритм контроля перегрузки T..."  +/
Сообщение от iZEN email(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 email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру