forum.opennet.ru - "Facebook протестировал новый алгоритм контроля перегрузки CO..." (16)

"Facebook протестировал новый алгоритм контроля перегрузки CO..."

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

"Facebook протестировал новый алгоритм контроля перегрузки CO..."	+/–
Сообщение от opennews (??), 19-Ноя-19, 12:50
Facebook опубликовал результаты экспериментов с новым алгоритмом контроля перегрузки (congestion control) - COPA, оптимизированным для передачи видеоконтента. Алгоритм предложен исследователями из Массачусетского технологического института. Предложенный для тестирования прототип COPA написан на С++, открыт под лицензий MIT и включён в состав mvfst, развиваемой в Facebook реализации протокола QUIC... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51893
Ответить \| Правка \| Cообщить модератору

Оглавление

Почти всё что угодно работает лучше чем CUBIC или newreno - дефолты линуха и фря, Ivan_83 (ok), 15:52 , 19-Ноя-19, (6) +5
Я перешёл с yeah на htcp Разницы не заметил, поскольку потери нездоровая тема , Аноним (1), 12:50 , 19-Ноя-19, (1) –7

Ох, дай угадаю ты тестировал westwood и htcp скачивая файлик к себе Тогда у ме, Ivan_83 (ok), 15:58 , 19-Ноя-19, (7) +1

Не, раздавал файлы для китайского ботнета На кубике передача падала до нуля каж, Аноним (1), 16:20 , 19-Ноя-19, (10) +1
нет, только что тестировал, скрипт вроде такогоfor I in seq 100 110 do for, edo (ok), 17:32 , 15-Мрт-20, (15)

Хм, при забитой скачиванием файла полосе браузер не может скачивать картиночки , Аноним (1), 00:43 , 10-Фев-21, (17)

Они ошибочно считают, что всё видео должно быть потоковым , Аноним (2), 13:15 , 19-Ноя-19, (2) –6

у них есть свой интернет, как у гугля , Andrey Mitrofanov_N0 (??), 14:06 , 19-Ноя-19, (4)

https en wikipedia org wiki Internet orgне взлетел, Имя (?), 17:06 , 19-Ноя-19, (11)

На первый взгляд отдает чем-то похожим на ledbat, Аноним (3), 13:43 , 19-Ноя-19, (3)
Здесь интересно совместное проживание устройств с разными алгоритмами в одной се, little Bobby tables (?), 14:10 , 19-Ноя-19, (5)

Ну забирают, и фиг с ними Кубик вообще фуфел У меня msd умеет в рамках одного пр, Ivan_83 (ok), 16:00 , 19-Ноя-19, (8)

Если новый алгоритм вытесняет и кубик и ббр, то и вашему фуфелу на всех биндинга, little Bobby tables (?), 17:56 , 19-Ноя-19, (12) –1

чудес не бывает или пропускная способность выше и душить соседей, или пропускна, edo (ok), 17:36 , 15-Мрт-20, (16)

Крутота, спасибо Facebook, ушел делать убийцу YouTube, Иван (??), 16:07 , 19-Ноя-19, (9)
Да уж, пейсбук и перегрузка сора -- прям символично , Michael Shigorin (ok), 22:55 , 21-Ноя-19, (14) +1

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

1. Сообщение от Аноним (1), 19-Ноя-19, 12:50 –7 +/–

Я перешёл с yeah на htcp. Разницы не заметил, поскольку потери нездоровая тема. Ну т.е. между westwood и htcp разницы точно 0 было, а вот насчёт cubic не уверен. Для bbr нужно включать QoS, я ещё подумаю об этом.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #17

2. Сообщение от Аноним (2), 19-Ноя-19, 13:15 –6 +/–

Они ошибочно считают, что всё видео должно быть потоковым.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

3. Сообщение от Аноним (3), 19-Ноя-19, 13:43 +/–

На первый взгляд отдает чем-то похожим на ledbat

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

4. Сообщение от Andrey Mitrofanov_N0 (??), 19-Ноя-19, 14:06 +/–

> Они ошибочно считают, что
...у них есть свой интернет, как у гугля.
>всё видео должно быть потоковым.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #11

5. Сообщение от little Bobby tables (?), 19-Ноя-19, 14:10 +/–

Здесь интересно совместное проживание устройств с разными алгоритмами в одной сетке. Ведь вроде как BBR душит CUBIC  - соединения с BBR забирают полосу у кубиковских.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #16

6. Сообщение от Ivan_83 (ok), 19-Ноя-19, 15:52 +5 +/–

Почти всё что угодно работает лучше чем CUBIC или newreno - дефолты линуха и фряхи, просто потому что они для средней температуры по больнице.
Для потокового видео на всяких линках с большим RTT (50+мс) и потерями у меня очень хорошо работали hybla и htcp.
Притом на момент тестов htcp в линухе работал сильно лучше чем во фряхе (при максимально одинаковых настройках стёков), тогда она кажется была ещё 10.х.
До гуглового у меня руки не дошли попробовать.

Ещё забавно, но они видимо не в курсе, что приложение может для каждого отдельного сокета выставлять свой СС, те можно в одном приложении юзать CUBIC, newreno, htcp, hybla и что угодно ещё на разных сокетах, разом.
Те если видим что нужны малые задержки - ставим один СС, если гоним потокове видео или файл - другой СС и нет проблем.
Не обязательно извращатся и делать мегаумный и мегасложный СС который сам эвристиками будет разруливать.

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

7. Сообщение от Ivan_83 (ok), 19-Ноя-19, 15:58 +1 +/–

Ох, дай угадаю: ты тестировал westwood и htcp скачивая файлик к себе?)
Тогда у меня интересная инфа: СС отрабатывает только на передачу.
westwood и элинойс и ещё что то из старья - вообще полный мусор, у меня они в локалке даже 100м не могли заполнить в один конект.
htcp - очень быстро разгоняется, он сразу линк в полку забивает и старается так держать, но в случае потерь восстанавливает скорость несколько хуже, чем hybla.
hybla тоже не плохо рагоняется на старте, но всё же у неё плавный старт а не взрывообразный, но фишка в том, что она очень корректно держит скорость при потерях и rtt от 50 ей не мешает.
кубик, ньюрено и кто то там ещё - так, середнячки, не полный мусор но и толку с них мало.
Ещё когда то на швабре была статья с тестированием разных СС, у них результаты не релевантные моим получились.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10, #15

8. Сообщение от Ivan_83 (ok), 19-Ноя-19, 16:00 +/–

Ну забирают, и фиг с ними.
Кубик вообще фуфел.
У меня msd умеет в рамках одного приложения на разные биндинги вешать разные СС :)
Те СС можно задавать для конкретного сокета, а не только для всей системы разом. Это работает на фре и линухах.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #12

9. Сообщение от Иван (??), 19-Ноя-19, 16:07 +/–

Крутота, спасибо Facebook, ушел делать убийцу YouTube

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

10. Сообщение от Аноним (1), 19-Ноя-19, 16:20 +1 +/–

Не, раздавал файлы для китайского ботнета. На кубике передача падала до нуля каждые несколько секунд, была такая лесенка. Когда поменял, до нуля больше не провисало. А вествуд на файфае лучше был емнип, так что не так уж и плох он.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

11. Сообщение от Имя (?), 19-Ноя-19, 17:06 +/–

>свой интернет
https://en.wikipedia.org/wiki/Internet.org
не взлетел

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

12. Сообщение от little Bobby tables (?), 19-Ноя-19, 17:56 –1 +/–

Если новый алгоритм вытесняет и кубик и ббр, то и вашему фуфелу на всех биндингах, сокетах, фряхах и линухах  не поздоровится. ну и фиг с ним. продолжайте наблюдение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

14. Сообщение от Michael Shigorin (ok), 21-Ноя-19, 22:55 +1 +/–

Да уж, пейсбук и перегрузка сора -- прям символично.

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

15. Сообщение от edo (ok), 15-Мрт-20, 17:32 +/–

> Тогда у меня интересная инфа: СС отрабатывает только на передачу.
нет, только что тестировал, скрипт вроде такого
for I in `seq 100 110`; do
    for A in bbr cubic htcp yeah; do
        sysctl net.ipv4.tcp_congestion_control=$A
        sleep 3
        time curl -s -o /dev/null http://somebigfile
    done 2>&1 | tee tcptest$I
done

разница весьма заметная, среднее квадратичное:
bbr       100
yeah      128
cubic     136
htcp      137
scalable  153
dctcp     162
westwood  174
hybla     176
lp        177
illinois  206
highspeed 236
bic       239
cdg       296
veno      313
nv        314
vegas     343

вторая итерация, уже с bbr на сервере:
bbr        57
cubic      67
htcp       65
yeah       65

так что серверные настройки важнее, но клиентские тоже влияют

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

16. Сообщение от edo (ok), 15-Мрт-20, 17:36 +/–

> Здесь интересно совместное проживание устройств с разными алгоритмами в одной сетке. Ведь
> вроде как BBR душит CUBIC  - соединения с BBR забирают
> полосу у кубиковских.
чудес не бывает. или пропускная способность выше и душить соседей, или пропускная способность ниже, зато fair (и потенциально недозагружен канал в случае потерь/неравномерной пропускной способности как у wifi или сотовых сетей).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

17. Сообщение от Аноним (1), 10-Фев-21, 00:43 +/–

Хм, при забитой скачиванием файла полосе браузер не может скачивать картиночки. Поможет ли QoS? Наверное же поможет, да? Должен?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 19-Ноя-19, 12:50	–7 +/–
Я перешёл с yeah на htcp. Разницы не заметил, поскольку потери нездоровая тема. Ну т.е. между westwood и htcp разницы точно 0 было, а вот насчёт cubic не уверен. Для bbr нужно включать QoS, я ещё подумаю об этом.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7, #17

2. Сообщение от Аноним (2), 19-Ноя-19, 13:15	–6 +/–
Они ошибочно считают, что всё видео должно быть потоковым.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #4

3. Сообщение от Аноним (3), 19-Ноя-19, 13:43	+/–
На первый взгляд отдает чем-то похожим на ledbat
Ответить \| Правка \| Наверх \| Cообщить модератору

4. Сообщение от Andrey Mitrofanov_N0 (??), 19-Ноя-19, 14:06	+/–
> Они ошибочно считают, что ...у них есть свой интернет, как у гугля. >всё видео должно быть потоковым.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #11

5. Сообщение от little Bobby tables (?), 19-Ноя-19, 14:10	+/–
Здесь интересно совместное проживание устройств с разными алгоритмами в одной сетке. Ведь вроде как BBR душит CUBIC - соединения с BBR забирают полосу у кубиковских.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #8, #16

6. Сообщение от Ivan_83 (ok), 19-Ноя-19, 15:52	+5 +/–
Почти всё что угодно работает лучше чем CUBIC или newreno - дефолты линуха и фряхи, просто потому что они для средней температуры по больнице. Для потокового видео на всяких линках с большим RTT (50+мс) и потерями у меня очень хорошо работали hybla и htcp. Притом на момент тестов htcp в линухе работал сильно лучше чем во фряхе (при максимально одинаковых настройках стёков), тогда она кажется была ещё 10.х. До гуглового у меня руки не дошли попробовать. Ещё забавно, но они видимо не в курсе, что приложение может для каждого отдельного сокета выставлять свой СС, те можно в одном приложении юзать CUBIC, newreno, htcp, hybla и что угодно ещё на разных сокетах, разом. Те если видим что нужны малые задержки - ставим один СС, если гоним потокове видео или файл - другой СС и нет проблем. Не обязательно извращатся и делать мегаумный и мегасложный СС который сам эвристиками будет разруливать.
Ответить \| Правка \| Наверх \| Cообщить модератору

7. Сообщение от Ivan_83 (ok), 19-Ноя-19, 15:58	+1 +/–
Ох, дай угадаю: ты тестировал westwood и htcp скачивая файлик к себе?) Тогда у меня интересная инфа: СС отрабатывает только на передачу. westwood и элинойс и ещё что то из старья - вообще полный мусор, у меня они в локалке даже 100м не могли заполнить в один конект. htcp - очень быстро разгоняется, он сразу линк в полку забивает и старается так держать, но в случае потерь восстанавливает скорость несколько хуже, чем hybla. hybla тоже не плохо рагоняется на старте, но всё же у неё плавный старт а не взрывообразный, но фишка в том, что она очень корректно держит скорость при потерях и rtt от 50 ей не мешает. кубик, ньюрено и кто то там ещё - так, середнячки, не полный мусор но и толку с них мало. Ещё когда то на швабре была статья с тестированием разных СС, у них результаты не релевантные моим получились.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #10, #15

8. Сообщение от Ivan_83 (ok), 19-Ноя-19, 16:00	+/–
Ну забирают, и фиг с ними. Кубик вообще фуфел. У меня msd умеет в рамках одного приложения на разные биндинги вешать разные СС :) Те СС можно задавать для конкретного сокета, а не только для всей системы разом. Это работает на фре и линухах.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #12

9. Сообщение от Иван (??), 19-Ноя-19, 16:07	+/–
Крутота, спасибо Facebook, ушел делать убийцу YouTube
Ответить \| Правка \| Наверх \| Cообщить модератору

10. Сообщение от Аноним (1), 19-Ноя-19, 16:20	+1 +/–
Не, раздавал файлы для китайского ботнета. На кубике передача падала до нуля каждые несколько секунд, была такая лесенка. Когда поменял, до нуля больше не провисало. А вествуд на файфае лучше был емнип, так что не так уж и плох он.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7

11. Сообщение от Имя (?), 19-Ноя-19, 17:06	+/–
>свой интернет https://en.wikipedia.org/wiki/Internet.org не взлетел
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

12. Сообщение от little Bobby tables (?), 19-Ноя-19, 17:56	–1 +/–
Если новый алгоритм вытесняет и кубик и ббр, то и вашему фуфелу на всех биндингах, сокетах, фряхах и линухах не поздоровится. ну и фиг с ним. продолжайте наблюдение.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

14. Сообщение от Michael Shigorin (ok), 21-Ноя-19, 22:55	+1 +/–
Да уж, пейсбук и перегрузка сора -- прям символично.
Ответить \| Правка \| Наверх \| Cообщить модератору

15. Сообщение от edo (ok), 15-Мрт-20, 17:32	+/–
> Тогда у меня интересная инфа: СС отрабатывает только на передачу. нет, только что тестировал, скрипт вроде такого for I in `seq 100 110`; do for A in bbr cubic htcp yeah; do sysctl net.ipv4.tcp_congestion_control=$A sleep 3 time curl -s -o /dev/null http://somebigfile done 2>&1 \| tee tcptest$I done разница весьма заметная, среднее квадратичное: bbr 100 yeah 128 cubic 136 htcp 137 scalable 153 dctcp 162 westwood 174 hybla 176 lp 177 illinois 206 highspeed 236 bic 239 cdg 296 veno 313 nv 314 vegas 343 вторая итерация, уже с bbr на сервере: bbr 57 cubic 67 htcp 65 yeah 65 так что серверные настройки важнее, но клиентские тоже влияют
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7

16. Сообщение от edo (ok), 15-Мрт-20, 17:36	+/–
> Здесь интересно совместное проживание устройств с разными алгоритмами в одной сетке. Ведь > вроде как BBR душит CUBIC - соединения с BBR забирают > полосу у кубиковских. чудес не бывает. или пропускная способность выше и душить соседей, или пропускная способность ниже, зато fair (и потенциально недозагружен канал в случае потерь/неравномерной пропускной способности как у wifi или сотовых сетей).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

17. Сообщение от Аноним (1), 10-Фев-21, 00:43	+/–
Хм, при забитой скачиванием файла полосе браузер не может скачивать картиночки. Поможет ли QoS? Наверное же поможет, да? Должен?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1