Зачем выбирать ядро ​​с малой задержкой вместо обычного или реального времени?


105

После установки Ubuntu Studio 12.04 я обнаружил, что она использует ядро ​​с низкой задержкой. Я искал, почему и как изменить обратно на реальный или общий. Но похоже, что эта часть Linux не так много освещена.

В: Почему ядро ​​с малой задержкой предпочитает обычное ядро ​​или ядро ​​реального времени?

PS: я уже прочитал ответы на этот вопрос и этот пост.


3
+1 потому что это должно быть довольно хороший вопрос, если все в тупике. Я все еще не знаю разницы между ядрами с малой задержкой, универсальными и в реальном времени. Если -realtimeэто в реальном времени, то что означает -rt? А что там с -preemptядром? Я буду благодарен gemue2010, он проделал довольно хорошую работу, объясняя это, но это все еще не объясняет все.
Hitechcomputergeek

Ответы:


61

Вот несколько простых рекомендаций, которые помогут вам понять, какое ядро ​​и в каком порядке вам следует протестировать в соответствии с вашим вариантом использования.

  • Если для вашей системы не требуется низкая задержка, используйте ядро ​​-generic.
  • Если вам нужна система с низкой задержкой (например, для записи звука), пожалуйста, используйте ядро ​​-preempt в качестве первого выбора. Это уменьшает задержку, но не жертвует функциями энергосбережения. Он доступен только для 64-битных систем (также называемых amd64).
  • Если ядро ​​-preempt не обеспечивает достаточно низкой задержки для ваших нужд (или у вас 32-битная система), вам следует попробовать ядро ​​-lowlatency.
  • Если ядра -lowlatency недостаточно, вам следует попробовать ядро ​​-rt
  • Если ядро ​​-rt недостаточно стабильно для вас, вам следует попробовать ядро ​​-realtime

Справочный источник Ubuntu

Так что это зависит от того, что вы будете делать с вашим студийным дистрибутивом. Для большинства пользователей, которым требуется быстрое время отклика конечного пользователя, универсальный режим подойдет просто, для других, которым необходимо профессиональное редактирование видео, где даже простое удаление кадра недопустимо, требуется ядро ​​реального времени.

Для более полного и понятного поста в блоге, прочитайте эту ссылку


1
Я уже прочитал предыдущую статью, которую вы опубликовали. Во-вторых, насколько достоверны эти факты?
Starx

Ну, упомянутые там тесты говорят сами за себя. Если команда Ubuntu в первую очередь выбрала Latency, это должно быть причиной для этого. Итак, вы хотели знать различия, теперь вы делаете. Задача решена ?
Ubuntu

5
Нет .. Я не думаю, что проблема решена. Если ваш ответ что-то делает, это еще больше увеличивает мое любопытство.
Starx

9
Все ли это по-прежнему актуально в 2015 году? В -preempt, -rtи -realtimeядра не-больше не существует
naught101

51

Я автор поста, на который ссылается фанат Ubuntu: http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/

Это сообщение в блоге не представляет никакого факта, это только теория . На самом деле, так оно и есть: процессор «останавливается» чаще, чтобы увидеть, есть ли какие-то процессы, требующие немедленного внимания. Это означает, что эти процессы будут выполняться раньше других, поэтому вы не пропустите кадры при кодировании или будете иметь огромные задержки между щелчками мыши и смертью противника. Это не означает, что все процессы завершатся раньше: на самом деле процессор теряет большую часть своего времени, решая, какой процесс будет выполняться дальше, и переключая контекст. Таким образом, общее время выполнения больше, и поэтому никто не запускает вытесняемое ядро ​​на машинах веб-сервера или базы данных. Но лучше всего для игровых серверов лучше всего использовать ядро ​​с частотой 300 Гц (или даже 1000 Гц).

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

(stackexchange требует от меня ссылок / личного опыта: я инженер-электронщик, кровожадный нубгеймер, управляющий несколькими игровыми серверами на http://www.gamezoo.it ).

Так что, как правило, я бы сказал: если ваш процессор является мощным высокочастотным четырехъядерным процессором, работающим с большими числами, и вы обычно не открываете тонны веб-страниц при кодировании / декодировании / играх (да), вы могли бы просто попробуйте стандартное (или i686, или amd64, если они существуют) ядро ​​и имеют максимально возможную пропускную способность (т. е. необработанное вычисление числа, которое способен процессор). Если у вас возникли проблемы (они действительно должны быть незначительными) или ваша машина немного менее мощная, чем вершина рынка, выберите вариант -preempt.

Если вы работаете на младшей машине с одним или двумя ядрами, попробуйте опцию -lowlatency. Вы также можете попробовать -realtime, но вы обнаружите, что он имеет тенденцию блокировать процессы, пока те, которые работают в режиме реального времени, не закончили свою работу. Я считаю, что ядро ​​реального времени не является «ванильным», но имеет патч CONFIG_PREEMPT_RT. Я думаю, что ядра реального времени предназначены только для тех, кому нужно создавать одно приложение на встраиваемых системах, поэтому обычные пользователи настольных компьютеров не должны иметь реальных преимуществ, потому что они обычно запускают достаточное количество приложений одновременно.

Наконец, наиболее подходящие параметры ядра, если вы хотите самостоятельно перекомпилировать ядро, чтобы иметь рабочий стол с низкой задержкой:

PREEMPT=y

а также:

CONFIG_1000_HZ=y

Чтобы добавить немного энергосбережения, вы можете проверить это:

CONFIG_NO_HZ=y

Я заметил, что вы упомянули о поддержке серверов, я пытаюсь найти лучшее ядро ​​для выделенного сервера с исходным кодом (особенно CSGO). Большинство потоков CS, которые я нахожу, связаны с goldsrc, которому нужно ядро ​​1000 Гц. С srcds это плохо? если это не имеет значения, я просто придерживаюсь низкого уровня задержки, поскольку это то, что у меня есть сейчас (я изолирую ядра ЦП для 128-тиковых серверов srcds, так как в любом случае это не дает многопоточности).
Винсент Де Смет

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

4

Из цитируемого выше документа ( http://www.versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp )

  1. мягкая система реального времени даст уменьшенную среднюю задержку, но не гарантирует максимальное время отклика.
  2. Жесткая система реального времени всегда соблюдает требуемые сроки (100 процентов), даже при самой низкой загрузке системы.
  3. По словам Ягмура [4], «в реальном времени работают с гарантиями, а не с необработанной скоростью».

В статье говорится, что жесткое ядро ​​реального времени безответно или ограничено по времени является наиболее важным свойством, поэтому иногда они задерживают некритическую активность, которая приводит к задержке, но для низкого уровня задержки или другого мягкого ядра реального времени пытаются уменьшить общую задержку, которая помогает в большинстве случаев. Из-за уменьшенного времени ожидания система работает быстро. Прочитайте статью внимательно.


Это правда, но нам нужно знать, какой вариант ядра соответствует какой «жесткости» системы реального времени.
Мелебиус

0

У меня есть этот старый ноутбук с двумя AMD A6-4400M на частоте 1600 МГц, который я использую экономно, когда нахожусь вне офиса, в основном для чтения электронной почты и просмотра случайных веб-сайтов. Было что-то, возможно, связанное с обновлениями программного обеспечения, что делает его безразличным. Что-то вроде набора дюжины символов, не видя первого. Часто виджет спрашивает, должен ли я принудительно выйти из процесса.

После sudo apt-get install linux-lowlatencyи перезагрузки стало плавно и отзывчиво. (uname -r 5.0.0-20-lowlatency.) Замечательно, я должен был переключиться много лет назад. Позвольте мне подчеркнуть ответ Семи: если вы не хотите выжать максимум из сервера, работающего с числами , переходите к -preempt !

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.