> Собственно ты словами и описываешь классический алгоритм."В теории, Петька, мы с тобой миллионеры". Классийческий алгоритм в его чистом виде на беспровлдке на вот это вот по реальному поведению не похож вообще. Огибающая фактически доступного бандвиза и то что он там себе мнил - две громадные разницы. Наверное, секрет в том что уйти в сэмплирование состояния раз в минуту - идея паршивая. Особенно - для беспроводки.
> Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую,
Лучший индикатор который я знаю это RTT. Я вижу вполне прямую корреляцию роста RTT c "линк перегружен" на почти всех типах линков. При том это довольно универсальная метрика. Ну вот например вафля. Может декларить 150Мбит рейт, но сделать 3 перепосылки. Или 75, но влупить за 1 раз. Если любопытно - зазырь что на этот счет Minstrel делает, но он там это делает где-то внутрях себя, а у многих других девайсов эти решения вообще фирмвар принимает по одному ему ведомым критериям. И этот фирмвар может и не вывешивать столько сведений наружу. И это, глядя на статистику minstrel'а я даже не знаю что там номинальной символьной скоростью назвать.
И вот кстати его эвристика работает довольно недурно, но вот у него таки есть доступ к весьма детальному статусу его железки. Специфично для его железки. Экспортировать ЭТО в TCP? А счастьем точно не зашибет? :)
> без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания
> данного вопроса.
Мое понимание вон того вопроса можно узреть выше. В отличие от тебя я видел что кажет тот же минстрел в статистике. И как он скорости выбирает. И поэтому напрягаюсь даже просто назвать конкретное число как символьную скорость, чтобы в "хидер вписать" (неизвестно зачем, это же на всю толпу делится малопредсказуемым образом).
> Почитай потом, например, про проблему медленного старта (это название этапа, если
> что) и как её пытается решить гибридный старт (а это алгоритм).
> А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.
А ты посмотри как вообще современные беспроводные интерфейсы работают и включи мозг на тему того что это сеть - так что я не очень понимаю какое число можно вписать в хидер IP как бандвиз и что оно должно означать.
Не, если ты по проводному эзернету, по одной TCP конекции гонишь данные, ок, там понятно. А если это 20 endpoint'ов на прыгающей как блоха беспроводке, да еще зависит от действий ремотных систем, то чего туда писать и какой смысл это все несет?
> Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR
> будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности
> не столкнётся с аналогичным потоком BBR.
Тем не менее, нахальность обеспечивает ему лучший трекинг "огибающей доступного бандвиза линка". Это довольно быстро фаломорфирующая в беспроводке величина если ты не понял. Варьируется от нуля (сота пропала/линк отпал) до весьма солидных значений в сотни мегабитов и довольно резво.
> Странно, но реальные тесты BBR показывают, что он - говно.
Смотря кто и что тестировал. Кто-то вообще пробовал оттестировать следование алгоритмов огибающей реально доступного бандвиза линка и прикинуть процент утилизации того что было фактически доступно? Это довольно сложно - и я плохо представляю себе как это сделать воспроизводимо.
Понимаешь, когда качается с 1/3 доступной скорости линка или 10-секундный вылет апгрейдится до минутного - мне реально похрен что твои синтетические бенчи рисуют. И победитель для меня тот кто избавит от этого трешака.
> Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом.
Ага, блин, а теперь сядь в поезд и забенчи свой долбаный кубик оттуда на ходу. Он при минимальных прорехах покрытия вообще в тыкву превратится и тыквой и останется, навечно. И вместо "интернета" будет "мучение". Нет, даже не диалапного уровня. Правда как это сделать воспроизводимо я не знаю, с моей стороны это некое "усреднение фактического опыта". После вот таких бенчей ты может быть и осознаешь что мне не нравится в кубиках.
> Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг
> при максимальной для него нагрузке).
И явно лучше адаптируется к изменчивым линкам. Не обваливаясь в полное дно так легко и просто как кубик.
> В локальной сети при пинге 1 мс он проседает процентов на 30%!
А в беспроводке твой кубик может и на почти бесконечность процентов слить. А сколько процентов записать протоколу почти не качающему данные вообще? :)
> Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у
> всех десктопных Линуксов.
Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR. И знаешь, когда чатик в поезде датыкается на минуту, меня это больше напрягает чем 10 или даже 30% бандвиза в локалке.
Ну и применительно к браузеру - я не думаю что основное применение браузеров это кач файлов с локалки, так что вон те 30% никто не увидит. Зато на беспроводке юзеры будут ощущать себя куда лучше чем сейчас.
