The OpenNET Project / Index page

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

Netflix предложил реализацию алгоритма контроля перегрузок TCP BBR для FreeBSD

10.09.2019 16:12

Для FreeBSD компанией Netflix подготовлена реализация алгоритма контроля перегрузок TCP (congestion control) BBR (Bottleneck Bandwidth and RTT), который позволяет значительно увеличить пропускную способность и сократить задержки передачи данных. В BBR применяются методы моделирования канала связи, прогнозирующие имеющуюся пропускную способность через последовательные проверки и оценку времени приема-передачи (RTT), без доведения канала связи до начала потери пакетов или задержек в передаче.

  1. Главная ссылка к новости (https://reviews.freebsd.org/D2...)
  2. OpenNews: Netflix опубликовал патчи с реализацией TLS для ядра FreeBSD
  3. OpenNews: В различных реализациях протокола HTTP/2 выявлено 8 DoS-уязвимостей
  4. OpenNews: Уязвимости в TCP-стеках Linux и FreeBSD, приводящие к удалённому отказу в обслуживании
  5. OpenNews: Google опубликовал BBR, новый алгоритм контроля перегрузки TCP
  6. OpenNews: Отчёт о развитии FreeBSD за второй квартал 2019 года
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: freebsd, tcp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (19) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:11, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Это, видимо, Netflix так избавляется от FreeBSD в продакшене, да?
    Как сифилитик в том анекдоте:

    Посадили в тюрьму наркомана и сифилитика. Сидят, у сифилитика нос
    отвалился, тот его берет и выкидывает за решетку. Затем ухо
    отваливается, сифилитик выкидывает его за решетку. Со вторым ухом такая
    же ситуация. Наркоман смотрел, смотрел и говорит: - Я смотрю ты
    потихоньку отсюда съ^W сваливаешь?

     
     
  • 2.2, qwerty123 (??), 22:32, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +17 +/
    >Это, видимо, Netflix так избавляется от FreeBSD в продакшене, да?

    Да, 1 сентября сильно ударило по аналитическому сообществу...

     
  • 2.16, Аноним (16), 22:39, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я думаю им просто надоело свои патчи поддерживать самостоятельно, к тому же в свете отказа от фрибсд они ещё и оказались ненужными.
     

  • 1.6, Ivan_83 (ok), 04:14, 11/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Возможно что это моя переписка в личке с одним из разрабов который там работает года 3-4 назад о том что линух при максимально одинаковых настройках отдаёт статик файлы в 2-5 раз быстрее фри на линках с ртт более 60мс и потерями - иницировала то что потом вылилось и rack и вот в это.
     
     
  • 2.7, Анонимный прохожий (?), 05:36, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +13 +/
    > Возможно что это моя переписка в личке с одним из разрабов который там работает года 3-4 назад

    Один знакомый таксист рассказывал дочке офицера...

     
     
  • 3.13, Ivan_83 (ok), 14:06, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее инфа что линукс лучше отдаёт в таких условиях просто дошла до нужных ушей :)
     
  • 2.8, Catwoolfii (ok), 08:25, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >линух при максимально одинаковых настройках отдаёт статик файлы в 2-5 раз быстрее фри на линках с ртт более 60мс и потерями

    Что-то на сказки похоже...

     
     
  • 3.9, Ivan_83 (ok), 12:13, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Увы но нет.
    Тестировал качая файлы с компа с вендой в другом городе в 5 часовых поясах, там последняя миля - вифи.
    Те и rtt 70мс и потери.
    Там где с фрёй получалось стабильно 300-600 килобайт/сек с линуксом было уже до 2 мегабайт/сек.
    При этом был один и тот же конфиг nginx (с поправкой на kqueue()/epoll()), и максимально близкие тюнинги сетевого стёка, даже tcp cc был одинаковый - htcp с одинаковыми настройками.
    Чтобы я ни делал с фрёй мне не удалось выжать скорости сопоставимые с линухом.
    Это было на новый год, где то году в 2016 или 2017. С тех пор я столь обстоятельно не повторял тестирование.

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

     
     
  • 4.10, DeadLoco (ok), 13:43, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, проблема именно в том, что "настройки максимально близкие". У фри все немножко более иначе, нежели чем. Она имеет специфические крутилки, и на такое же положение одинаковых ручек реагирует не так, как линукс.

    Надо было выставлять не одинаковые настройки, а оптимальные для фри и оптимальные для линукса. И тогда уже сравнивать.

     
     
  • 5.11, grsec (ok), 13:52, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > У фри все немножко более иначе, нежели чем.

    О этом все говорят, но что и как крутить не знают даже разрабы.

     
  • 5.12, Ivan_83 (ok), 14:04, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Когда я копался внутри там было видно что логикики в tcp cc коде и вокруг у линуха сильно больше.
    В остальном там настройки были из серии о том, что Сысоев для нгинха рассказывал в 2007 году - те буфера. Из того о чём он не говорил было как раз выставление tcp cc = htcp и одинаковых настроек самого htcp.
    Файл лился из tmpfs, да и с такими скоростями его хоть с флешки можно было читать.

    В любом случае при таких скоростях всё сводилось к тому, что tcp во фре восстанавливал скорость после ошибок сильно хуже чем tcp в линуксе и ничего с этим было сделать невозможно.
    Я пробовал и другие tcp cc, было примерно тоже самое - линукс всегда был лучше.

     
  • 3.14, qwerty123 (??), 15:33, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/

    исходный файл рандомный что б не жался

    $ dd if=/dev/urandom of=AAA bs=1M count=256

    bsd 2 bsd:

    bsd1$ time scp AAA bsd2:/data/
    AAA  100%  256MB  75.2MB/s   00:03    

    real 0m6.418s
    user 0m2.484s
    sys 0m1.660s

    debian 2 debian:

    linux1$ time scp AAA linux2:/data/
    AAA  100%  256MB  42.7MB/s   00:06    

    real 0m10.855s
    user 0m3.192s
    sys 0m0.392s

    криптография одинаковая.

    вот такие котята.

     
     
  • 4.15, Ivan_83 (ok), 15:38, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь тоже самое с rtt=70ms, и дропами пакетов на уровне 0,5-1% хотя бы.
     
     
  • 5.17, qwerty123 (??), 23:35, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/

    >А теперь тоже самое с rtt=70ms

    А где я тебе найду 70ms, если от Дублина до Воронежа максимум 50 могу выжать? =)
    Шейпером как-то не комильфо.

    Не, на самом деле фуфло все это. Я юзаю в проектах как linux разных сборок, так и freebsd.
    В общем случае одинаково, и обе ложаться при предельных для шасси показателях PPS плюс-минус 5%.


     
     
  • 6.20, Ivan_83 (ok), 17:55, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Во фре кажется ng_car что то такое умел имитировать.
    Или можешь бобины оптики по 100км штук 30 хотя бы, и вланами на свиче или медюками собрать мосты на требуемую длину :)

    У меня москва-иркутск и в последнем вифи на последней миле (полёт минимум километр), по пути там неизвестно что творится :)
    Одно время rtt был до 110, меньше 68 мс не видел.

     
     
  • 7.21, Аноним (21), 12:04, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вроде проще с ipfw pipe
     
  • 5.18, qwerty123 (??), 23:40, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А теперь тоже самое с rtt=70ms, и дропами пакетов на уровне 0,5-1% хотя бы.

    мне это напомнило анекдот
    ---
    а потом рабочие поставили в японскую пилораму рельсу.
    хряк - сказала пила.
    ага! - радостно сказали рабочие.
    ---

     
     
  • 6.19, Аноним (19), 09:24, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > а потом рабочие поставили в японскую пилораму рельсу.

    Так Иван сразу в начале ветки и сказал про рельсу (про фиговое качество связи - задержки и потери пакетов). Следуя Вашей аналогии - японская пила на рельсе сказала "хряк" и разлетелась, а совковая "Дружба" сказала "ням-ням, вкусно, тащи следующую".

     
     
  • 7.22, qwerty123 (??), 12:20, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Следуя Вашей аналогии

    Для FreeBSD реализовано 8 (восемь) алгоритмов контроля перегрузок.
    Все немного по разному себя ведут в разных ситуациях с полной загрузкой канала.

    cc_cdg(4) - CDG Congestion Control Algorithm
    cc_chd(4) - CHD Congestion Control Algorithm
    cc_cubic(4) - CUBIC Congestion Control Algorithm
    cc_dctcp(4) - DCTCP Congestion Control Algorithm
    cc_hd(4) - HD Congestion Control Algorithm
    cc_htcp(4) - H-TCP Congestion Control Algorithm
    cc_newreno(4) - NewReno Congestion Control Algorithm
    cc_vegas(4) - Vegas Congestion Control Algorithm


    Бла-бла про совковые пилы оставте для своей курилки или что там у вас.

     

  • 1.23, Qazzz (ok), 16:36, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мдее, аналитеги, посмотрите недавнее выступление netfix
    https://itsfoss.com/netflix-freebsd-cdn/

    видео
    http://mirror.onet.pl/pub/mirrors/video.fosdem.org/2019/Janson/netflix_freebs

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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