1. Ну, вам бесполезны, но в целом для многотредовых програм собирать статсы по перцентилю сильно проще для HDR, чем заниматься обходом деревьев и блокировать их изменения. Например, полезно глянуть перцентили по сетевым задержкам, но там такие скорости…
2. Конкретно в этой имплементации пошли по легкому пути, но никто не мешает сделать автоподстройку, как верхнего, так и нижнего диапазона. Часть крайних данных может потеряться, да, но для приближенных вычислений это допустимо.
HDR выглядит явным фаворитом уже из описания — плоская (недревовидная) структура данных, вычисление всех нужных перцентилей (например, 25, 50, 95, 99, да вообще любых, а не только один 95) одновременно, регулируемый баланс точность/память, практически мгновенная агрегация (сложить списки поэлементно)…
Быстрая синхронизация для SMP систем (нет необходимости использовать отдельный мьютекс, можно применять CAS на сам счетчик, или вообще атомарный инкремент, если такой поддерживается процессором).
Даже логарифм значения не обязательно вычислять, если работать с бинарным представлением float-а — в старших битах мантиссы фактически записан индекс нужной ячейки (относительно группы ячеек, покрывающей диапазон [1… 2) ), правда, тогда вычислять сам перцентиль будет сложнее, т.к. проиндексированные таким образом ячейки будут сгруппированы в логарифмической шкале неравномерно.
И самостоятельно реализуется весьма легко, при необходимости, алгоритм абсолютно прямой.
Похоже на продвинутый полиморфикс (поликапролактон). Тот тоже плавится при 60С, и тоже весьма крепкий, хотя 500 кг узкая лента явно не выдержит (прочность 16МПа, т.е. 1.6 кг/мм2). Тут каким-то образом волокна ориентируют, видимо.
Честно говоря, странно видеть, что уязвимость перезаписи кучи стеком (или наоборот) до сих пор существует на 64-битных системах. Что мешает использовать для кучи и для стека адреса, разнесенные на сто тысяч гигабайт (условно)? Ядро же живет себе в верхней половине адресного пространства и его это не беспокоит.
http://www.cameramouse.org/
https://www.codeproject.com/Articles/498193/Mouse-Control-via-Webcam
https://fingermouse.codeplex.com/
…
это только первое, что гуглится по запросу «virtual mouse via webcam»
В линуксе htcp работает по другому, думаю, из-за более продвинутого алгоритма управления tcp-буфером. На фиксированном размере буфера скорость должна быть одинаковой.
BBR требует ко всему ещё и возможность отсылать пакеты через указанные интервалы, во фре такой функциональности пока нет, а в линуксе для корректной работы BBR надо дополнительно настраивать tc (traffic control)
Да, htcp лучший CC на фре на текущий момент, использую его с самого начала.
Во первых, это плохая поддержка нового оборудования. Я даже на домашнем десктопе был вынужден перейти на Linux из-за невозможности использования двух мониторов на встроенной видяхе Intel на Broadwell, хотя до этого использовал только FreeBSD. Не без проблем, конечно, но как-то их решал, а вот вопрос с видеокартой был последним гвоздем. На серверах тоже не все гладко бывает, хотя проблемы возможны везде, в том числе и под Linux. Железо приходится подбирать всегда, промахи стоят денег )
Второе — это вышеупомянутая проблема TCP-стека FreeBSD с большим кол-вом соединений, из-за которой на высокомощных серверах ресурс заканчивается гораздо быстрее, чем если они отдают тот же контент под Linux. Ставить просто больше серверов выйдет весьма дороже.
Третий очень важный фактор — отсутствие поддержки TCP congestion control algorithm BBR, который в Linux появился в прошлом году. Когда-то его запилят и во фре, но терять в качестве обслуживания клиентов все это время нельзя.
То, что во фре все более продуманно, чем в линуксе, это факт. И нет множества разных дистрибутивов, каждый со своими заморочками; значительное внимание уделяется обратной совместимости. Для хостинга это серьезный фактор, на самом деле.
Лично я считаю, что FreeBSD незаслуженно обделена вниманием разработчиков, многие из которых считают, что раз в Linux скомпилировалось и запустилось, то дело сделано.
Развиваться в таких условиях FreeBSD приходится куда труднее, и то, что ей это удается делать, это уже большое достижение.
У FreeBSD есть одна весьма неприятная особенность в сетевом стеке — он плохо масштабируется относительно кол-ва TCP-сессий :(. Увеличение кол-ва TCP-сессий в несколько раз приводит к непропорционально большему потреблению CPU.
У Сысоева так всё нормально работало ещё в рамблере.
Честно говоря, не понимаю, каким образом тот факт, что у Игоря Сысоева все работало нормально, опровергает то, что нагрузка на CPU растет быстрее, чем нагрузка на сеть.
Похоже вы просто не умеете его готовить.
Вам виднее, конечно же ))
Со своей стороны могу заметить, что я ещё в 2007 году запускал больше 1.2Гбита на apache!!! 1.2 (с 4-х обычных sata дисков, ssd не было), когда ещё слово nginx никто не слышал ) Сами понимаете, какие в то время были процессоры.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=113885 — тоже пришлось в ядре покопаться, чтобы диски нормально отдавали контент.
1. Сетевая карта с MSI-X аппаратно умеет разбрасывать конекты по прерываниям.
2. Если карта унылая (ну типа там рылотек) то можно практически тоже самое делать через net.isr.dispatch=deferred, при этом схема будет такой: обработчик прерывания будет по быстрому сваливать пакеты в очередь netisr а та их сама раскладывать по ядрам. При этом ещё не плохо бы и сами очереди увеличить, чтобы за время между прерыванием/разгребанием не успевало переполнится. netstat в помощь.
Приятно видеть, что Вы хорошо владеете теорией. Проблемы же, как обычно бывает, находятся в практике )
Жуть. Я думал полинг с ядра давно выкинули. )
Сейчас, когда меньше 8 ядер на сервере уже трудно найти, в поллинге особого смысла уже нет. Но все же не стоит забывать, что процессорные ядра занимаются не столько вычислениями, сколько обменом данными, а с этим есть определенные проблемы. За счет того, что все нужные данные находятся в одном и том же кеше одного ядра, в режиме поллинга на обработку условных 10М пакетов тратится 1с работы одного ядра, а в режиме MSI-X на десятке ядер это может быть уже суммарных 5с работы одного ядра.
Далеко не факт что возьмут, как минимум оно не под 11, а лучше бы под 12
Не вижу, как эти три строчки одной проверки могут вдруг оказаться несовместимыми с 11-кой или 12-кой )
Потому что nginx пилят под фрю, а линух так, вторично.
Есть разные, виснет и на отдаче контента с дисков, и чисто сеть+проц (ну как «чисто», диски все равно используются, но уже не так интенсивно).
Возможно, у нас сильно специфический конфиг ядра, он весьма отличается от GENERIC…
Увы, x.0 релизы давно уже не выпускались сразу в продакшн качестве, та же 10-ка только к 10.3 стала более-менее безпроблемной, и все равно 9-ка часто работает лучше в одних и тех же условиях.
Надеюсь, в 11.1 много пофиксят, если зависния не уйдут — придется разбираться и с ними )
Также надеюсь, что в 11.1 добавят tcp_сс BBR, иначе в большинстве случаев будет прямой смысл ставить Linux.
Исторически у нас FreeBSD используется с самого начала, Linux ставили только по необходимости (если софт, например, работает под линуксом существенно лучше чем под фрей). Ещё несколько лет назад у FreeBSD с Linux был паритет — в каких-то задачах фря была существенно лучше (nginx+aio, например), в каких-то линукс.
Сейчас FreeBSD весьма отстает, увы ((
Глючит 11.0, я ж написал, что она падучая. Паник не было, тихо, но надежно виснет, непредсказуемо, гарантированно воспроизвести не получается. PR не открывал, каюсь.
Право же, не стоит ))
Рад что Вам понравилось, надеюсь, статья также попадется на глаза и другим пострадавшим пользователям FreeBSD, ведь эта индийская MiTM прокси до сих пор активна и отсылает неправильные TCP-пакеты…
2. Конкретно в этой имплементации пошли по легкому пути, но никто не мешает сделать автоподстройку, как верхнего, так и нижнего диапазона. Часть крайних данных может потеряться, да, но для приближенных вычислений это допустимо.
Быстрая синхронизация для SMP систем (нет необходимости использовать отдельный мьютекс, можно применять CAS на сам счетчик, или вообще атомарный инкремент, если такой поддерживается процессором).
Даже логарифм значения не обязательно вычислять, если работать с бинарным представлением float-а — в старших битах мантиссы фактически записан индекс нужной ячейки (относительно группы ячеек, покрывающей диапазон [1… 2) ), правда, тогда вычислять сам перцентиль будет сложнее, т.к. проиндексированные таким образом ячейки будут сгруппированы в логарифмической шкале неравномерно.
И самостоятельно реализуется весьма легко, при необходимости, алгоритм абсолютно прямой.
http://www.cameramouse.org/
https://www.codeproject.com/Articles/498193/Mouse-Control-via-Webcam
https://fingermouse.codeplex.com/
…
это только первое, что гуглится по запросу «virtual mouse via webcam»
А так идея отличная )
Да, htcp лучший CC на фре на текущий момент, использую его с самого начала.
Второе — это вышеупомянутая проблема TCP-стека FreeBSD с большим кол-вом соединений, из-за которой на высокомощных серверах ресурс заканчивается гораздо быстрее, чем если они отдают тот же контент под Linux. Ставить просто больше серверов выйдет весьма дороже.
Третий очень важный фактор — отсутствие поддержки TCP congestion control algorithm BBR, который в Linux появился в прошлом году. Когда-то его запилят и во фре, но терять в качестве обслуживания клиентов все это время нельзя.
Лично я считаю, что FreeBSD незаслуженно обделена вниманием разработчиков, многие из которых считают, что раз в Linux скомпилировалось и запустилось, то дело сделано.
Развиваться в таких условиях FreeBSD приходится куда труднее, и то, что ей это удается делать, это уже большое достижение.
Честно говоря, не понимаю, каким образом тот факт, что у Игоря Сысоева все работало нормально, опровергает то, что нагрузка на CPU растет быстрее, чем нагрузка на сеть.
Вам виднее, конечно же ))
Со своей стороны могу заметить, что я ещё в 2007 году запускал больше 1.2Гбита на apache!!! 1.2 (с 4-х обычных sata дисков, ssd не было), когда ещё слово nginx никто не слышал ) Сами понимаете, какие в то время были процессоры.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=113885 — тоже пришлось в ядре покопаться, чтобы диски нормально отдавали контент.
Приятно видеть, что Вы хорошо владеете теорией. Проблемы же, как обычно бывает, находятся в практике )
Сейчас, когда меньше 8 ядер на сервере уже трудно найти, в поллинге особого смысла уже нет. Но все же не стоит забывать, что процессорные ядра занимаются не столько вычислениями, сколько обменом данными, а с этим есть определенные проблемы. За счет того, что все нужные данные находятся в одном и том же кеше одного ядра, в режиме поллинга на обработку условных 10М пакетов тратится 1с работы одного ядра, а в режиме MSI-X на десятке ядер это может быть уже суммарных 5с работы одного ядра.
Не вижу, как эти три строчки одной проверки могут вдруг оказаться несовместимыми с 11-кой или 12-кой )
Исключая пул IO-тредов, да? )
Возможно, у нас сильно специфический конфиг ядра, он весьма отличается от GENERIC…
Увы, x.0 релизы давно уже не выпускались сразу в продакшн качестве, та же 10-ка только к 10.3 стала более-менее безпроблемной, и все равно 9-ка часто работает лучше в одних и тех же условиях.
Надеюсь, в 11.1 много пофиксят, если зависния не уйдут — придется разбираться и с ними )
Также надеюсь, что в 11.1 добавят tcp_сс BBR, иначе в большинстве случаев будет прямой смысл ставить Linux.
Сейчас FreeBSD весьма отстает, увы ((
Рад что Вам понравилось, надеюсь, статья также попадется на глаза и другим пострадавшим пользователям FreeBSD, ведь эта индийская MiTM прокси до сих пор активна и отсылает неправильные TCP-пакеты…
Фото/видео — тут уже нет.