| |
| 2.2, Специалист по всему (?), 00:28, 18/09/2016 [^] [^^] [^^^] [ответить]
| +9 +/– |
Тем что BBR это патч для линукса, который можно скомпилить и включить, а Remy это исследовательский прототип, который полюбому тормозит или вообще работает не в реалтайме, а в симуляторе.
| | |
| 2.3, kleemhead (?), 03:03, 18/09/2016 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Локальная сеть google это вам не WAN
Вот вот. Взять их оптику в нищих районах пендосии, кэш-серверы ютьюба у ВСЕХ крупных провайдеров, слегка принять во внимание инфраструктуру дата-центров и возвести в квадрат. Как-то так можно оценить их WAN. А в остальном, прекрасная маркиза, все хорошо, все хорошо.
| | |
| 2.7, Аноним (-), 18:05, 18/09/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Локальная сеть google это вам не WAN с кучей вредителей
У гугля локальной сетью с их ютубом - вся планета. И тут то как раз оказывается что существующие существующие алгоритмы работают с всякими wi-fi и 4G просто никак.
Например в беспроводных сетях некоторое выпадение пакеров - обычное явление и может быть следствием помех, движения или просто попыткой прокачать больше чем физический уровень может обеспечить, от чего все эти рено и кубики плющит. Они начинают осциллировать (!!!) и постепенно загоняют себя в режим когда данные почти не идут вообще. Скорость прокачки становится спасибо если треть возможностей канала.
> больно умные алгоритмы для повышения аттаки.
Кубики и рено в беспроводных сетях сами себя DoS'ят. Что гуглу не нравится - у пользователей ютуб икает. Единственный кто всерьез это учитывает из существующих - CDG (caia delay gradient) который использует чем-то похожие подходы и с недавних пор включен в ядро Linux. С ним по беспроводке скорость может быть куда лучше. Но гугл видимо нашел фатальный недостаток: cdg придумали не они.
| | |
|
| 1.4, rm_ (ok), 12:25, 18/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Им стоило бы начать с объяснения чем не устроил Illinois, кроме того что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?
| | |
| |
| 2.8, Аноним (-), 18:17, 18/09/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Им стоило бы начать с объяснения чем не устроил Illinois, кроме того
> что НеизобретёнЗдесь. Или их хрень лучше только древних рено и кубика?
По беспроводным сетям из того что в Linux есть сколь-нибудь вменяемо работает разве что cdg. Который есть только в паре свежих версий ядер Linux.
Упомянутый алгоритм чем-то напоминает подходы cdg, но немного с другой стороны.
| | |
|
| 1.6, Ivan_83 (ok), 14:51, 18/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Кубик и рено не лучшие, оно и не удивительно.
Но есть htcp, hybla которые в локалках весьма работают, да и в диком инете тоже.
Тестов что то не видать.
| | |
| |
| 2.9, iZEN (ok), 00:37, 19/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
 >Кубик и рено не лучшие, оно и не удивительно.
Неудивительно. Ведь они придуманы в эпоху проводных сетей с последующей адаптацией к реалиям.
https://habrahabr.ru/post/168407/
///---
К сожалению, CUBIC, который используется по умолчанию во всех дистрибутивах, совершенно не подходит, например, для 3G-соединений.
<...>
Как видите, CUBIC в отстающих. Он значительно повысил RTT на полной утилизации 3G канала, в то время как Westwood+ и NewReno более-менее справляются с этой проблемой.
<...>
Как видно из графика, у CUBIC относительно большое количество ретрансмиссий
<...>
В то же время, он лидирует в скорости передачи данных за единицу времени.
Что это значит? Это значит, что с использованием Westwood+ или NewReno вы сможете комфортней серфить интернет, пока у вас скачивается большой файл.
---///
| | |
| |
| 3.13, Аноним (-), 20:13, 19/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Поэтому в Linux рулит CDG. А что рулит в bsd? Или их еще не отпустило?
| | |
| |
| 4.16, iZEN (ok), 20:52, 19/09/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Поэтому в 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
Что загрузишь - то и будет.
> Или их еще не отпустило?
В смысле?
| | |
| |
| 5.17, Аноним (-), 19:41, 20/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Этот NewReno - как и в линуксах докостыленный вариант reno? :) Хз как в бсд но в линуксах тамошний пиленый-перепиленый рено не сильно дружит с беспроводкой. CDG интересен тем что рассматривает delay gradient как критерий перегрузки. Потери пакетов его не очень смущают, ему рост RTT важенее и это куда более удачный критерий на беспроводке. На неидеальном беспроводном канале это работает лучше. На остальных каналах это тоже вполне адекватный критерий как правило. Сабж судя по описанию чем-то похож, он тоже не считает потери пакетов главным критерием для понижения скорости. А всякие reno/vegas и подобные по смыслу из-за излишнего упования на потери пакетов как критерий душат скорость соединения на ровном месте, а то и вовсе коллапсируют.
| | |
|
|
| 3.19, Ivan_83 (ok), 20:15, 20/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Болт на них - ламеры :)
Я сам для себя тестил в немного других условиях:
RTT > 70
потери пакетов
При этом мне нужен был поток стабильный в 4-10 мегабит - смотрел IPTV через пол страны: Иркутск-Москва.
Короче: всё говно кроме hybla и htcp, притом последний тоже не очень то работал.
hybla - единственно с чем поток был стабильный и просмотр без залипаний.
htcp - он лучше hybla когда RTT по меньше и потерь меньше, особенно это заметно в локалках.
И вывод них тоже идиотский, ведь важно какой СС на сервере а не у тебя, потому что сёрфинг+скачивание - это всё получение данных с сервера.
| | |
|
|
| 1.10, iZEN (ok), 00:57, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Как включить нужный алгоритм 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
Испытываем радость или печаль - в зависимости от предъявляемых требований и удовлетворения ожиданий.
| | |
| |
| 2.20, Ivan_83 (ok), 20:20, 20/09/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Это ты мне рассказываешь?)))
У меня мой msd/msd_lite умеет выставлять алгоритмы на сокеты.
Те можно на соединения принимаемые с биндиного сокета на 192.168.0.1 выставлять htcp,
а на соединения принимаемые с сокета прибинденого на 172.16.0.1 ставить скажем vegas (чтобы они страдали :) ).
И потом у меня лежит hybla для фри, сам портировал...
Но у фри там что то сломано относительно линуха, потому что я тестил htcp который есть и там и там и фря у меня сливала 3-5 раз по скорости.
| | |
|
| 1.11, AS (??), 18:41, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>>> BBR оценивает потолок пропускной способности канала
непонял я что эти горбы под 1000Мгб/s в Заббиксе наблюдать должен ?
| | |
| |
| 2.14, mumu (??), 20:29, 19/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Эта технология хороша только для 100% загруженных каналов, где ориентироваться постоянно только на потери, это значит иметь постоянно проблемы с потерями. Там эта технология выглядит логичной и полезной.
| | |
| |
| 3.18, Аноним (-), 19:43, 20/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Если канал не имеет потерь и не загружен на 100% то и планировщик ему не требуется по большому счету - что так пакеты можно немедленно слать что эдак. Проблемы начинаются когда эта идилия нарушается. И совсем не круто если то RTT уходит в небеса, то кач со скоростью 30% канала.
| | |
|
| 2.15, mumu (??), 20:31, 19/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
В таких 100% загруженных сетях вы будете на графиках видеть только "горбы" пропавших пакетов. А с этой технологией как-раз всё будет тихо-мирно ;)
| | |
|
|
