RT-ядро на десктопе. Имеет право быть или тварь дрожащая?

Я вижу разницу! Вот с Zen - не видел, а с RT - вижу. С ним система отзывчивей

Ты GeekBench прогони хотя б на 6.1.38 LTS и 6.1.33 RT, чтобы было хоть о чём-то поговорить, кроме «вижу», «отзывчивее», «вырос», «плавнее» и пр.

Может еще стоит что-то поправить в конфигах?

Ох уж эти перфекционисты. Я тут оперативку новую поставил. Завёл. Дай думаю тайминги подкручу. Теперь знаю где сброс КМОП на этой материнке

wayland+hyprland куда еще отзывчивей

Куда угодно.

Говоря RT подразумевают потерю throughput в пользу уменьшения latency. Потому не радуйся раньше времени, лучше замерь все внимательно. Если бы все было радужно то все бы сидели на RT ядрах.

Обычно, после оптимизаций ядра, радостных криков и «может поправить еще пару конфигов» появляются темы с тэгом «пишу из горящего танка»😁

а где можно почитать? Я бы поставил rt

Я не эксперт по RT и даже навести на хорошую литературу не могу, но все RTOS предлагают именно такой обмен, маленькие и предсказуемые задержки ценой общей производительности.
А еще знаю что RT ядра Linux любят музыканты которые используют десктоп с DAW и нужным софтом в качестве синтезатора.

Да я сам не эксперт, Но звучит немного противоречиво, потому что latency и связывают с производительностью

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

Не, есть latency и есть throughput они взаимопротиворечат, хотя в некотором диапазоне нагрузки может наблюдаться линейное масштабирование, т.е. throughput растет без роста latency

GeekBench прогони

Во-первых, это копроприентарный телеметрический пылесос недоступен в моей стране. А во-вторых, каким образом усредненные кукурузные баллы соотносятся с фактическом быстродействием в прикладных задачах?

все бы сидели на RT ядрах

Я бы не был так категоричен, видя что практически все на десктопах обкладывают дебиан флатпаками, на сервера тулят арч и генту, и по части rt - ни в зуб ногой.

Кто-то пользуется сабжем в быту?

Ну, я как-то пробовал, во времена, когда под RT ещё можно было собрать Нвидиевский блоб. Потом перестал.

А что у тебя

uname -a

У ядра есть несколько настроек по поводу RT, вот здесь можно посмотреть Kconfig.preempt

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

PREEMPT думаю должно работать на ПК довольно стабильно

или

uname -a

PREEMPT_RT активна, полет отличный. На какие драйвера обратить внимание? Mesa? Нагружал и под wine и нативными игрями. Звук все отлично. Даже wol для r8169 не отвалился.

Тайминги это дроч, цифры ради цифр.

На дохлом проце и мощной видюхе дают 60 кадров вместо 56. И частота тоже

Ну если работает то и хорошо, может в шестерке все уже и допилили до стабильного состояния

С драйверами, если они разрабатывались без учета PREEMPT_RT и тут внезапно наступает «replacing various locking primitives (spinlocks, rwlocks, etc.) with preemptible priority-inheritance aware variants, enforcing interrupt threading and introducing mechanisms to break up long non-preemptible sections» могут произойти разные интересные вещи

Я как раз об этом, это копейки и ниачом. Было бы «убил вечер на подбор таймингов - получил x2 fps», тогда да.

Ээээ, когда до 60 не хватает 4 кадров - это катастрофа. Сихронизации нет - будет вата в управлении, визуально иногда выглядит как 30. 56 и 60 - небо и земля. Разве что экран с VRR это решает

Zen linux-lqx пробовал? Еще linux-cachyos советуют.

Zen пробовал. Никакого буста в сравнении с дефолтным манжаровским не получил.

А вот геморой с его обновлением - получил.

А во-вторых, каким образом усредненные кукурузные баллы соотносятся с фактическом быстродействием в прикладных задачах?

Так там проверяются не усреднённые кукурузные баллы, а ещё прикладные задачи – File compression, HTML5 Browser, PDF Render, Image Processing, Clang Compilation, Text processing и пр.

копроприентарный телеметрический пылесос недоступен

Ну тогда довольствуйся гуманитарными «стало отзывчивей», «на глаз FPS вырос», «вижу разницу» и дальше, что можно сказать, лол.

В киберпунке, eve и всякой синтетике фпсы, посля тюнинга первичек и выставления balanced вместо relaxed для вторичек, подросли на 6-14 процентов...неплохой результат 10 минутной дрочки кмк.

Кстати, а можете показать скорость чтения/записи на tmpfs разделе с дефолтными и затюнеными. Например в kdiskmark

5.15.0-76-lowlatency #83~20.04.1-Ubuntu SMP PREEMPT, полёт нормальный.

Потестил на 6.1.38, в unigine-superposition разницы между rt и не rt нет, а вот в byte-unixbench на многопоточной нагрузке rt проигрывает не rt почти 60%.

Кому интересно детали:

не rt:

32 CPUs in system; running 32 parallel copies of tests

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0 1292392460.3 110744.9
Double-Precision Whetstone                       55.0     281852.3  51245.9
Execl Throughput                                 43.0      54018.1  12562.4
File Copy 1024 bufsize 2000 maxblocks          3960.0    2324349.0   5869.6
File Copy 256 bufsize 500 maxblocks            1655.0     599601.0   3623.0
File Copy 4096 bufsize 8000 maxblocks          5800.0    6629064.0  11429.4
Pipe Throughput                               12440.0   72469091.3  58254.9
Pipe-based Context Switching                   4000.0    8595323.6  21488.3
Process Creation                                126.0     222388.0  17649.8
Shell Scripts (1 concurrent)                     42.4     128404.3  30284.0
Shell Scripts (8 concurrent)                      6.0      18119.1  30198.5
System Call Overhead                          15000.0   81529002.9  54352.7
                                                                   ========
System Benchmarks Index Score                                       22731.1

rt:

32 CPUs in system; running 32 parallel copies of tests


System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0 1277060335.7 109431.0
Double-Precision Whetstone                       55.0     279420.5  50803.7
Execl Throughput                                 43.0      14701.3   3418.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     406645.0   1026.9
File Copy 256 bufsize 500 maxblocks            1655.0      94881.0    573.3
File Copy 4096 bufsize 8000 maxblocks          5800.0    1497178.0   2581.3
Pipe Throughput                               12440.0   67906249.3  54587.0
Pipe-based Context Switching                   4000.0    7187764.7  17969.4
Process Creation                                126.0      40188.5   3189.6
Shell Scripts (1 concurrent)                     42.4      59245.7  13973.0
Shell Scripts (8 concurrent)                      6.0       6230.3  10383.8
System Call Overhead                          15000.0   75191437.3  50127.6
                                                                   ========
System Benchmarks Index Score                                        9656.3

Нужно понимать, что realtime computing и hight performance computing – вещи отнюдь не эквивалентные. А как правило – вообще ортогональные.

Оно то понятно. Подобные пиковые нагрузки при обыденной эксплуатации не встретить.

Вопрос, чем-таки померять, окромя мангохуда...

Насколько я знаю под RT ещё и железо тюнят, как минимум latency для PCI, и вручную настраивают планировщик для realtime задач. И есть мнение что нынешние ядра и без realtime патчсета так же хороши, но при этом более универсальны. Realtime тюнинг всё таки подразумевает узкую заточку под определённые задачи выполняемые конкретным софтом всей системы, а не просто установку «другого ядра», чтобы не знаю что, чтобы посмотреть ваще.

Это как в автоведре движок заменить на гоночный, работающий на метаноле и эффективный только в узком диапазоне оборотов, и без замены всего остального, типа коробки передач. И при этом в гонках собственно не участвовать, не думать о том в каких именно гонках, и даже не планировать этим всем заниматься. Пердеть ведро будет громко, да. Но того же эффекта можно достичь поставив «пердлявую» выхлопную диаметром в 10 см.

Всё вышеизложенное моё IMHO. Да, для желающих поиграть напомню что у нас в абсолютно обычном ядре c шедулером CFS есть, помимо умолчального для всех процессов SCHED_OTHER, SCHED_FIFO, SCHED_RR и SCHED_DEADLINE. А так же SCHED_IDLE для того чтобы что нибудь например считалось в фоне и не мешало кино смотреть.

man sched, я так думаю, а realtime ядро нужно оставить тому кто реально знает зачем ему оно.

Зачем гонять синтетический бенч, если требуется производительность отзывчивость в конкретных задачах? Если уж упомянуты были игры, надо в играх FPS сравнивать — тоже вполне объективный показатель, но на реальной полезной юзеру задаче (дискуссии про пользу и вред видеоигр разводить не будем), а не в попугаях.

Зачем гонять синтетический бенч

Затем:

Single-Core
  Running File Compression
  Running Navigation
  Running HTML5 Browser
  Running PDF Renderer
  Running Photo Library
  Running Clang
  Running Text Processing
  Running Asset Compression
  Running Object Detection
  Running Background Blur
  Running Horizon Detection
  Running Object Remover
  Running HDR
  Running Photo Filter
  Running Ray Tracer
  Running Structure from Motion

а вот в byte-unixbench на многопоточной нагрузке rt проигрывает не rt почти 60%.

Вот в это можно легко поверить.

А если вместо

32 CPUs in system; running 32 parallel copies of tests

запустить на 30 CPUs (15 настоящих ядрах, я так понимаю), а на оставшемся ядре пустить cyclictest, то станет ясно, зачем RT, и что оно работает: вместо задержек в сотни микросекунд и даже более 1 мс будут только десятки микросекунд и изредка немногим более 100 мкс (OSADL Latency plots).

И?

С каких пор geekbench измеряет что-то кроме raw throughput, и с каких пор raw throughput влияет на десктопную отзывчивость системы?

Думаю с таким же успехом можно приоритет выше поставить для игрового процесса и таймер ядра увеличить. Если и так работает, то хорошо, значит планировщику хватает времени обработать все нужные процессы и потоки. Интересно, как оно поведет в CPU зависимых играх.

Имеет право, если у тебя стал отзывчивее процесс с SCHED_RR. Если просто система стала отзывчивее — то проведи двойной слепой тест. Если просто FPS вырос, а волосы стали чище и шелковистее, то ты сам знаешь, откуда этот эффект.

Я не вижу применения RT ядрам в быту. Больше скажу - мы и в проде (а он у нас очень и очень latency-sensitive) от них отказались, потому как изолированием ядер и прибиванием процессов гвоздями к ядрам (или хотя бы к сокетам) можно добиться 95% результата при гораздо меньших трудозатратах. До тех пор пока у Вас не возникает необходимости приоритизировать user-space vs interrupt-handlers (и там, реально, нужно очень хорошо понимать что Вы делаете) - не нужно оно Вам, от слова совсем.

Ну тогда довольствуйся гуманитарными «стало отзывчивей», «на глаз FPS вырос», «вижу разницу» и дальше, что можно сказать, лол.

Но-но-но. На некоторых гуманитарных специальностях полно матана. Кое-кому преподают программирование. Всем гуманитариям преподают логику. Можно ли выпуститься с гуманитарной специальности типичным ГСМ? Можно. Но и у технарей полно способов упороться. Гуманитарий увлеченно смотрит и пересказывает «Тайны воды»? Тем временем какой-нибудь технарь обмазывается «Новой хронологией».

Это все измерение производительности. Realtime снижает производительность. Но при этом уменьшает задержки. Зачем ставить realtime и измерять при этом пиковую производительность – непонятно.

Сихронизации нет - будет вата в управлении, визуально иногда выглядит как 30.

А разве нельзя просто VSync вырубить в игре и будут тебе честные 56? Ну может с редким тирингом(и то не факт что будет).

Ничо не знаю, я уже на телек с VRR нацелился, думаю он решит все проблемы

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