Для FreeBSD компанией Netflix подготовлена реализация алгоритма контроля перегрузок TCP (congestion control) BBR (Bottleneck Bandwidth and RTT), который позволяет значительно увеличить пропускную способность и сократить задержки передачи данных. В BBR применяются методы моделирования канала связи, прогнозирующие имеющуюся пропускную способность через последовательные проверки и оценку времени приема-передачи (RTT), без доведения канала связи до начала потери пакетов или задержек в передаче.Подробнее: https://www.opennet.me/opennews/art.shtml?num=51463
Это, видимо, Netflix так избавляется от FreeBSD в продакшене, да?
Как сифилитик в том анекдоте:Посадили в тюрьму наркомана и сифилитика. Сидят, у сифилитика нос
отвалился, тот его берет и выкидывает за решетку. Затем ухо
отваливается, сифилитик выкидывает его за решетку. Со вторым ухом такая
же ситуация. Наркоман смотрел, смотрел и говорит: - Я смотрю ты
потихоньку отсюда съ^W сваливаешь?
>Это, видимо, Netflix так избавляется от FreeBSD в продакшене, да?Да, 1 сентября сильно ударило по аналитическому сообществу...
Я думаю им просто надоело свои патчи поддерживать самостоятельно, к тому же в свете отказа от фрибсд они ещё и оказались ненужными.
Возможно что это моя переписка в личке с одним из разрабов который там работает года 3-4 назад о том что линух при максимально одинаковых настройках отдаёт статик файлы в 2-5 раз быстрее фри на линках с ртт более 60мс и потерями - иницировала то что потом вылилось и rack и вот в это.
> Возможно что это моя переписка в личке с одним из разрабов который там работает года 3-4 назадОдин знакомый таксист рассказывал дочке офицера...
Скорее инфа что линукс лучше отдаёт в таких условиях просто дошла до нужных ушей :)
>линух при максимально одинаковых настройках отдаёт статик файлы в 2-5 раз быстрее фри на линках с ртт более 60мс и потерямиЧто-то на сказки похоже...
Увы но нет.
Тестировал качая файлы с компа с вендой в другом городе в 5 часовых поясах, там последняя миля - вифи.
Те и rtt 70мс и потери.
Там где с фрёй получалось стабильно 300-600 килобайт/сек с линуксом было уже до 2 мегабайт/сек.
При этом был один и тот же конфиг nginx (с поправкой на kqueue()/epoll()), и максимально близкие тюнинги сетевого стёка, даже tcp cc был одинаковый - htcp с одинаковыми настройками.
Чтобы я ни делал с фрёй мне не удалось выжать скорости сопоставимые с линухом.
Это было на новый год, где то году в 2016 или 2017. С тех пор я столь обстоятельно не повторял тестирование.С rack у меня проблема в том, что тот фреймворк который они добавили жрёт у меня проц весьма сильно в виртуалках на виртуалбоксе.
Возможно, проблема именно в том, что "настройки максимально близкие". У фри все немножко более иначе, нежели чем. Она имеет специфические крутилки, и на такое же положение одинаковых ручек реагирует не так, как линукс.Надо было выставлять не одинаковые настройки, а оптимальные для фри и оптимальные для линукса. И тогда уже сравнивать.
> У фри все немножко более иначе, нежели чем.О этом все говорят, но что и как крутить не знают даже разрабы.
Когда я копался внутри там было видно что логикики в tcp cc коде и вокруг у линуха сильно больше.
В остальном там настройки были из серии о том, что Сысоев для нгинха рассказывал в 2007 году - те буфера. Из того о чём он не говорил было как раз выставление tcp cc = htcp и одинаковых настроек самого htcp.
Файл лился из tmpfs, да и с такими скоростями его хоть с флешки можно было читать.В любом случае при таких скоростях всё сводилось к тому, что tcp во фре восстанавливал скорость после ошибок сильно хуже чем tcp в линуксе и ничего с этим было сделать невозможно.
Я пробовал и другие tcp cc, было примерно тоже самое - линукс всегда был лучше.
исходный файл рандомный что б не жался$ 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:03real 0m6.418s
user 0m2.484s
sys 0m1.660sdebian 2 debian:
linux1$ time scp AAA linux2:/data/
AAA 100% 256MB 42.7MB/s 00:06real 0m10.855s
user 0m3.192s
sys 0m0.392sкриптография одинаковая.
вот такие котята.
А теперь тоже самое с rtt=70ms, и дропами пакетов на уровне 0,5-1% хотя бы.
>А теперь тоже самое с rtt=70ms
А где я тебе найду 70ms, если от Дублина до Воронежа максимум 50 могу выжать? =)
Шейпером как-то не комильфо.Не, на самом деле фуфло все это. Я юзаю в проектах как linux разных сборок, так и freebsd.
В общем случае одинаково, и обе ложаться при предельных для шасси показателях PPS плюс-минус 5%.
Во фре кажется ng_car что то такое умел имитировать.
Или можешь бобины оптики по 100км штук 30 хотя бы, и вланами на свиче или медюками собрать мосты на требуемую длину :)У меня москва-иркутск и в последнем вифи на последней миле (полёт минимум километр), по пути там неизвестно что творится :)
Одно время rtt был до 110, меньше 68 мс не видел.
вроде проще с ipfw pipe
> А теперь тоже самое с rtt=70ms, и дропами пакетов на уровне 0,5-1% хотя бы.мне это напомнило анекдот
---
а потом рабочие поставили в японскую пилораму рельсу.
хряк - сказала пила.
ага! - радостно сказали рабочие.
---
> а потом рабочие поставили в японскую пилораму рельсу.Так Иван сразу в начале ветки и сказал про рельсу (про фиговое качество связи - задержки и потери пакетов). Следуя Вашей аналогии - японская пила на рельсе сказала "хряк" и разлетелась, а совковая "Дружба" сказала "ням-ням, вкусно, тащи следующую".
>Следуя Вашей аналогииДля 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
Бла-бла про совковые пилы оставте для своей курилки или что там у вас.
Мдее, аналитеги, посмотрите недавнее выступление netfix
https://itsfoss.com/netflix-freebsd-cdn/видео
http://mirror.onet.pl/pub/mirrors/video.fosdem.org/2019/Jans...