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 мс не видел.
| |
|
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
Бла-бла про совковые пилы оставте для своей курилки или что там у вас.
| |
|
|
|
|
|
|
|