Linux-RT смерджили в master

это что теперь, все косяки RT на декстопе будут вылазить?

Только если ты специально укажешь ядру использовать реалтайм шедуллинг через опцию preempt=

Это что, теперь RT будет тормозить как десктоп.

У разработчиков чувство юмора на месте

Это при сборке, или при загрузке? А может на лету можно переключать? Я бы хотел.

Это уже давно можно переключать через kernel command line. То ли с версии 5.11, то ли с версии 5.17. Точно уже не помню.

Что-то было, но там же не всё было включено. Ведь поэтому и было отдельное ядро-РВ.

cast @ist76 @James_Holden

Всем насрать. Этот RT и не RT вовсе.

man soft real-time, man hard real-time

Вообще я сомневаюсь, что для музыки будет польза. Я игрался с ядрами и понял, что разница на уровне погрешности и... настроения системы. Потому что один день ты высекаешь на 64-ом буффере и не хрипит ничего, а другой день на ядре реального времени всё хрипит от иксрунов на 2048-ом буффере. И хрен его знает что влияет. Я так и не понял.

Есть только один RT — hard, остальное маркетинг с выдачей желаемого за действительное

Понятное дело, полной детерминистичности на системе общего назначения ты не добьешься. По идее, там среднее значение задержки несильно отличается от стандартного PREEMPT_FULL, отличается стабильность. В оптимальных условиях (когда нет значительного memory pressure), PREEMPT_RT должен давать более стабильную задержку.

Есть только один RT

Потому, что ты так сказал?

ну, как, на винде могут? На эполе могут? Системы общего назначения. Но я думаю, там просто есть правильные приоритеты, позволяющие приложениям правильно работать. Я никого не обвиняю, но и восторженных возгласов у меня уже нет.

И на винде, и на эполе точно так же не могут.

там просто есть правильные приоритеты

И в линуксе они есть. Сюрприз, правда?

Новость требует серьезнейшего внимания, что там конкретно.

Если кто-то следил за моей писаниной, то у меня выходило, что RT ядро как раз работает для low-latency аудио заметно хуже чем просто ванильное мейнстримное. (хотя там могут сильно влиять дистрибутивные патчи arch linux, я ванильное RT так и не попробовал пока). А тут такое

На винде и эполе ты загрузишь свою студию (да тот же Ардор) под завязку и только потом у тебя начнутся затыки по буфферам. А в линуксе это вообще непредсказуемо. Только «настроил» всё, поделился как всё круто и... вдруг всё становится озренеть как плохо. И самое главное - не менял НИЧЕГО и не обновлял. И тупо невозможно заставить работать как надо и никто не скажет почему, все тупо будут отсылать к тем же «туториалам», которые не работают.

Какая-то лабуда фоновая влияет, поэтому я все гашу скриптом перед тем как работать с аудио. А если не помогает, тогда перезагрузка помогает.

Плюс еще есть такая очень хреновая фишка - сильно гадит многоядерность и прыжки процессов между ядрами. Если в Ardour например отключить многопоточность движка, иксрунов может заметно меньше стать.

Плюс еще в Ardour есть подавление sleep состояния процессора, и если его активировать, то у меня заметно снижается уровень шума (!!!) входа аудиокарты.

Плюс - связка Ardour + pipewire с этими включенными фишками, ведет себя на голову лучше чем все остальное, по иксрунам.

Действительно, система общего назначения начинает вести себя недетерминистично, если создать большое давление на память и вынудить систему сбросить часть кеша. Никогда такого не было — и вот опять!

Также, мало кто осознает почему-то, что юзерспейсный аудио софт, включая даже pipewire, он рассчитан на мейнлайн ядро, и это RT ему как мертвому припарки.

У редхата есть какой-то демон, который управляет параметрами, связанными с производительностью, энергопотреблением и отзывчивостью. Там есть пресет для реалтайма. Насколько я понимаю, он ограничевает подстройку частоты процессора и мешает процессору переключаться в «энергосберегающие» P-state. Только я забыл, как этот демон называется

Вот. Нарыл. Есть новый tuned

Есть старый power-profiles-daemon

Почитай про MGLRU, например

реалтайма

Это просто баззворд, надо вникать каждый раз что именно имеется в виду. Для риалтайма, еще не значит что это именно для RT ядра, а не для обычного. SCHED_RR планирование, которое нужно для pulse/pipewire, доступно и в обычном ядре.

посмотрел realtime профиль от tuned что делает.

Пару параметров через sysctl меняет, и отрубает intel_pstate (лол)

И такое ощущение, что это для серверных сетевых задач больше.

И что это значит? Всмысле, какие у этого Linux-RT нововведения по сравнению с тем что было?

Я игрался с ядрами и понял, что разница на уровне погрешности и... настроения системы. Потому что один день ты высекаешь на 64-ом буффере и не хрипит ничего, а другой день на ядре реального времени всё хрипит от иксрунов на 2048-ом буффере

Я у себя выделил отдельные ядра (через isolcpu) под каждую звуковую софтину и стало стабильнее. Ядро стоковое какое-то там.

Вот-вот.

И что это значит? Всмысле, какие у этого Linux-RT нововведения по сравнению с тем что было?

Нововведение только одно - раньше RT-патч был отдельно от дерева исходников ядра, теперь его интегрировали в исходники ядра.

Интересно, починят ли теперь чуваки из ZFS поддержку RT.

лучше бы они туда Adeos залили.

расскажешь тёмному зачем этот риалтайм нужен? и темболее непонятно зачем он в фс

в эппле для «рилтамйм» приложений, типа аудиософта, отключается перекидывание процесса(ов) на другие процессорные ядра, в ляпексе это нужно делать вручную

Вопрос был о том, что даёт этот самый RT-патч.

Да, это весьма важно.

расскажешь тёмному зачем этот риалтайм нужен?

А на вас ИИ ругался матом? (комментарий)

Сегодня уже два часа они говорят и нет паузы. Так вот где рилтайм работает!!!

расскажешь тёмному зачем этот риалтайм нужен?

Для задач, чувствительных к задержкам. Например, видеоигры. Ну или работа со звуком.

и темболее непонятно зачем он в фс

Ты не понял. RT патчи затрагивали довольно ощутимое количество ядерного кода, и сторонние модули типа ZFS на таком не тестировались. Например, у меня на ведре 6.6-RT при нагрузке доступ к диску мог зависнуть.

странно как-то это, больше похоже на баг ламы, чем на фичу RT

больше похоже на баг ламы

Зовём @R_He_Po6oT.

про zfs понял, но не совсем понимаю откуда на не RT ядре задержки :) Грубо говоря если я запускаю на сегодняшнем ведре 100 тредов с for (1…1000) print timestamp – то впринципе у меня будет 100 копий 1000 таймштампов с дико минимальной погрешностью.

Вот у меня без RT есть АСТки, на каждом сервере достаточно средней руки крутится 500 одновременных звонков в режиме прокси голосового трафика и «не было никаких разрывов».

что нового даст RT? Тот же цпу сможет быстрее прокрутить эти 1000 циклов? Уменьшит «дико минимальную погрешность»?

это вообще про серверы и/или ноутбуки? На ноутбуках основные проблемы это оптимизация энергопотребления со всеми его проблемами, или RT и тут чем-то может помочь?

что нового даст RT?

Если хочется разобраться, то родительский коммит такой: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2004cef11ea072838f99bd95cefa5c8e45df0847

На самом деле я не знаю как ещё это объяснить. Вчера вечером поставил рилтаймовое ядро, сегодня перезагрузился в него и нет никакой задержки. Может просто совпадение. Но до этого я перезагружался и закрывал браузеры чтобы больше памяти отдать ламе, но паузы были большие. А теперь нету.

ну, как, на винде могут?

Тоже может тормозить на ровном месте, 1-2 минуты открывая пустой Notepad.

Вырубить гипертрединг, забить процесс на одно ядро, выключить плавающую частоту процессора, помолиться.

АТС-ки это очень хороший пример. Если софтина (АТС) говорит, что оно типа РТ приложение и хочет cтолько циклов за такой-то промежуток времени, то РТ ядро будет стараться чётко удовлетворить запрос, но если нагрузка слишком большая и ресурсов железки не хватает, то никакой магии не произойдёт и вычисления также будут буксовать, и по-идее в этом случае РТ ядро вовремя отрапортует, что запрос невыполним, и по-хорошему софтина должна понизить нагрузку, уменьшив битрейт или, например, в случае аудио софта - урезать количество голосов. Ну это на мой дилетантский взгляд.

сильно гадит многоядерность и прыжки процессов между ядрами

А если запинить на кор? cpu affinity, иначе говоря.

Ну тогда лучше, конечно.

Вообще я сомневаюсь, что для музыки будет польза.

Чисто от RT-PREEMPT ядра пользы будет, видимо, немного. Надо же еще user-space софту приоритеты повысить

Например для pipewire существует PipeWire:RT

Пару параметров через sysctl меняет, и отрубает intel_pstate (лол)

Не знаю как на ПК, а на ембеддщине вообще рекомендовали для таких систем делать CONFIG_PM=n чтобы никому не приходило в голову частоту менять или в сон уходить