Realtime: различия между версиями

Материал из ALT Linux Wiki
 
(не показано 19 промежуточных версий этого же участника)
Строка 1: Строка 1:
Операционная система ''реального времени'' (в отличии от системы ''общего назначения'') оптимизирована на уменьшение задержек реакции (''latency'') и детерминизм (''maximum latency'') при обработке событий. Применяется для построения систем в сферах телекоммуникаций, управления машинами, высокочастотной торговли, обработки звука и т.п.
Операционная система ''реального времени'' (в отличии от системы ''общего назначения'') оптимизирована на уменьшение задержек реакции (''latency'') и детерминизм (''maximum latency'') при обработке событий. Применяется для построения систем в сферах телекоммуникаций, управления машинами, высокочастотной торговли, обработки звука и т.п.<ref>[https://www.researchgate.net/publication/331290349 The Real-Time Linux Kernel: A Survey on PREEMPT_RT]</ref>


{{Attention|Экспериментальная сборка.}}
На данный момент в репозиторий ''Сизиф'' под архитектуру x86_64 собраны два ядра реального времени:
На данный момент в репозиторий ''Сизиф'' под архитектуру x86_64 собраны два ядра реального времени:


== kernel-image-xenomai ==
== kernel-image-xenomai ==
[[Файл:Xenomai.png|101px|right]]
[[Файл:Xenomai.png|101px|right]]
"Двойное ядро" состоящее из высокоприоритетного ко-ядра Cobalt реализующего различные (''skins'') RTOS API [https://xenomai.org/ Xenomai 3] и ядра линукс с I-Pipe (Adeos) патчем реализующим систему жёсткого реального времени. (Обратите внимание, что ядро Mercury не поддерживается.) Xenomai 3 может эмулировать RTOS API: pSOS+, uITRON, VxWorks, RTAI, VRTX, а так же содержит нативное API Alchemy и поддерживает Real-Time Driver Model (RTDM). [https://gitlab.denx.de/Xenomai/xenomai/wikis/Start_Here Документация на англ.]
"Двойное ядро" состоящее из высокоприоритетного ко-ядра Cobalt реализующего различные (''skins'') '''RTOS''' API [https://xenomai.org/ Xenomai 3] и ядра линукс с I-Pipe (Adeos) патчем реализующим систему жёсткого реального времени. Xenomai 3 может эмулировать RTOS API: pSOS+, uITRON, VxWorks, RTAI, VRTX, а так же содержит нативное API Alchemy и поддерживает Real-Time Driver Model (RTDM). [https://gitlab.denx.de/Xenomai/xenomai/wikis/Start_Here Документация на англ.]


Юзерспейс и специализированные тесты для этого ядра находятся в пакете <code>xenomai</code>.
Юзерспейс и специализированные тесты для этого ядра находятся в пакете <code>xenomai</code>.
Строка 12: Строка 11:
== kernel-image-rt ==
== kernel-image-rt ==
[[Файл:RealTimeLinux Logo1.png|111px|right]]
[[Файл:RealTimeLinux Logo1.png|111px|right]]
[https://wiki.linuxfoundation.org/realtime/start Real Time Linux] с [https://rt.wiki.kernel.org/ <code>PREEMPT_RT</code>] патчем (Ingo Molnar, Thomas Gleixner) реализующим POSIX real-time API. Иногда называемое <code>-rt</code> ядро.
[https://wiki.linuxfoundation.org/realtime/start Real Time Linux] с [https://rt.wiki.kernel.org/ <code>PREEMPT_RT</code>] патчем (Ingo Molnar, Thomas Gleixner) реализующим '''POSIX''' real-time API. Иногда называемое <code>-rt</code> ядро.


Считается, что ядра данного типа наиболее оптимально работают с ''vanilla'' конфигом. Поэтому была использована следующая методология создания конфига: defconfig + все опциональные модули из std_def ядра + тюнинг RT (отключено <code>NO_HZ</code>, отключены многие опции <code>_DEBUG</code> + прочие мелкие оптимизации).
Считается, что ядра данного типа наиболее оптимально работают с ''vanilla'' конфигом. Поэтому была использована следующая методология создания конфига: defconfig + все опциональные модули из std_def ядра + тюнинг RT (отключено <code>NO_HZ</code>, отключены многие опции <code>_DEBUG</code> + прочие мелкие оптимизации).
Строка 21: Строка 20:


Для тестирования этого ядра можно использовать пакет <code>linux-rt-tests</code>.
Для тестирования этого ядра можно использовать пакет <code>linux-rt-tests</code>.
Установка ядра:
# apt-get install update-kernel
# update-kernel -t rt
# reboot


= Тестирование ядра =
= Тестирование ядра =
Первоначально нужно определить пригодность вашей системы для реального времени.
Очень важно первоначально определить пригодность вашей системы для задач реального времени.


Базовый способ тестирования ядра реального времени это запуск утилиты <code>cyclictest</code> параллельно с созданием нагрузки на систему (например, запуск <code>unixbench</code>, сборку linux, <code>hackbench</code>, <code>gltestperf</code> в цикле) в течении ''длительного времени'' (не менее 24 часов). Пример запуска:
== cyclictest ==
Базовый способ тестирования ядра реального времени (POSIX API), это запуск утилиты <code>cyclictest</code> параллельно с созданием нагрузки на систему (генерацию нагрузки вы должны организовать сами, например, запуском <code>unixbench</code>, <code>stress-ng</code>, <code>hackbench</code>, <code>gltestperf</code> в цикле) в течении ''длительного времени'' (не менее 24 часов). Пример запуска:


     # cyclictest -a -m -Sp99
     # cyclictest -a -m -Sp99
Строка 36: Строка 41:
  T: 3 ( 1934) P:99 I:2500 C: 807593 Min:      1 Act:    2 Avg:    3 Max:    1886
  T: 3 ( 1934) P:99 I:2500 C: 807593 Min:      1 Act:    2 Avg:    3 Max:    1886


Для оценки результата следует смотреть на колонку <code>Max</code> показывающую время реакции на прерывания в ''микросекундах''. Есть примеры, на обычной системе, где Max доходит до 5-значных чисел. Пример вывода '''на RT ядре''' (SMI прерываний не было):
Для оценки результата следует смотреть на значения <code>Max</code> показывающие время реакции на прерывания в ''микросекундах''. (Есть примеры, на обычной системе, где Max доходит до 5-значных чисел.) Пример вывода '''на -rt ядре''' (SMI прерываний не было):


  T: 0 ( 4041) P:99 I:1000 C:4719726 Min:      1 Act:    2 Avg:    2 Max:      17
  T: 0 ( 4041) P:99 I:1000 C:4719726 Min:      1 Act:    2 Avg:    2 Max:      17
Строка 43: Строка 48:
  T: 3 ( 4044) P:99 I:2500 C:1887886 Min:      1 Act:    2 Avg:    2 Max:      14
  T: 3 ( 4044) P:99 I:2500 C:1887886 Min:      1 Act:    2 Avg:    2 Max:      14


Есть сообщения, что в некоторых системах Max остается в пределах 1-значного числа. Пример вывода '''на RT ядре при наличии SMI прерываний''', <code>cyclictest</code> запущен с дополнительной опцией <code>--smi</code>:
(Есть сообщения, что в некоторых системах Max остается в пределах 1-значного числа.) Пример вывода '''на -rt ядре при наличии SMI прерываний''', <code>cyclictest</code> запущен с дополнительной опцией <code>--smi</code>:
 
T: 0 (20422) P:99 I:1000 C:305390555 Min:      2 Act:    2 Avg:    3 Max:    297 SMI:    176
T: 1 (20423) P:99 I:1500 C:203593701 Min:      2 Act:    2 Avg:    3 Max:    318 SMI:    176
T: 2 (20424) P:99 I:2000 C:152695274 Min:      2 Act:    2 Avg:    2 Max:    274 SMI:    176
T: 3 (20425) P:99 I:2500 C:122156218 Min:      2 Act:    2 Avg:    3 Max:    340 SMI:    176
 
Опция <code>--smi</code> добавляет колонку <code>SMI</code>, которая показывает сколько было ''System Management Interrupts'' за время теста (счетчик прерываний считывается из MSR, если в вашем процессоре нет такого счетчика, то для их обнаружения можно использовать утилиту <code>hwlatdetect</code>). SMI прерывания могут ''значительно'' ухудшить показатели системы. В худшем случае, SMI прерывания способны давать задержки на многие миллисекунды. В системе ''пригодной'' для реального времени можно снизить число SMI через настройки или перепрошивку BIOS/firmware<ref>[https://www.coreboot.org/ coreboot]</ref>. Впрочем, полностью отключать эти прерывания не рекомендуется, так как они выполняют полезные функции для здоровья системы (контроль температуры и прочее). Часто полезно прочитать ''HPC Tuning Guide''<ref>[https://developer.amd.com/resources/epyc-resources/epyc-tuning-guides/ Пример Performance Tuning Guides для AMD]</ref> для вашего железа. Если задержки в системе ''превышает'' требуемый максимум, то она ''не пригодна'' для использования в реальном времени. Ещё один источник высоких задержек - не оптимизированные для реального времени драйвера оборудования (запрещающие прерывания на долгое время) или само железо (блокирующее процессор на долгое время).
 
== hwlatdetect ==
Тест (с помощью [https://www.kernel.org/doc/Documentation/trace/hwlat_detector.txt hwlat tracer]'а ядра) обнаруживает задержки создаваемые железом или firmware не зависимые от ядра, такие как SMI. (Не используйте его на продакшен системах или во время работы других тестов так как принцип его работы - нагружать процессоры на продолжительное время при запрещенных прерываниях, постоянно замеряя время (TSC) и определяя таким образом интервалы с пропусками.) Пример на системе с ''большими'' задержками:
 
# hwlatdetect
hwlatdetect:  test duration 120 seconds
    detector: tracer
    parameters:
        Latency threshold: 10us
        Sample window:    1000000us
        Sample width:      500000us
      Non-sampling period:  500000us
        Output File:      None
Starting test
test finished
'''Max Latency: 10099000us'''
Samples recorded: 67
Samples exceeding threshold: 67
 
== rtcheck ==
Небольшая утилита (от IBM) проверяющая, что запущенное ядро имеет свойства <code>-rt</code> ядра. Запускать с опцией <code>-v</code> для просмотра отчета.
 
== jitterdebugger ==
 
Более легкий в использовании аналог <code>cyclictest</code> (от Siemens и SUSE) с уклоном в воспроизводимый статистический анализ. ([https://github.com/igaw/jitterdebugger Домашняя страница.] [https://www.youtube.com/watch?v=wNQ24TFjzCw Видео презентация.] англ.) Пример запуска:
 
# jitterdebugger -v
 
== stress-ng ==
 
В <code>stress-ng</code> есть свой cyclic стрессор. Удобство, что можно сразу запустить параллельную нагрузку, неудобство, что формат вывода отличается от <code>cyclictest</code> и стрессоры не привязаны к конкретным ядрам, да и запускать больше 1 <code>--cyclic</code> стрессора не рекомендуется (это само по себе создаст избыточную нагрузку на ядро, при этом, почти не даст дополнительной полезной информации).


  T: 0 (12166) P:99 I:1000 C:16611118 Min:    2 Act:    2 Avg:    2 Max:    262 SMI:      64
  # stress-ng --cyclic 1 --cyclic-dist 1000 --cyclic-prio 99 --cyclic-sleep 10000 -t 1m
T: 1 (12167) P:99 I:1500 C:11074077 Min:    2 Act:    2 Avg:    2 Max:      50 SMI:      64
T: 2 (12168) P:99 I:2000 C:8305556 Min:      2 Act:    2 Avg:    2 Max:    248 SMI:      64
T: 3 (12169) P:99 I:2500 C:6644444 Min:      2 Act:    2 Avg:    2 Max:    250 SMI:      64


Опция <code>--smi</code> добавляет колонку <code>SMI</code>, которая показывает сколько было ''System Management Interrupts'' за время теста (счетчик прерываний считывается из MSR, если в вашем процессоре нет такого счастливого счетчика, то можно использовать утилиту hwlatdetect). SMI прерывания могут ''значительно'' ухудшить показатели системы. В худшем случае, SMI прерывания могут давать задержки на миллисекунды. В системе ''пригодной'' для реального времени можно снизить число SMI через настройки или перепрошивку BIOS/firmware<ref>[https://www.coreboot.org/ coreboot]</ref>. Часто полезно прочитать ''HPC Tuning Guide''<ref>[https://developer.amd.com/resources/epyc-resources/epyc-tuning-guides/ Пример Performance Tuning Guides для AMD]</ref> для вашего железа. Если задержки в системе ''превышает'' требуемый максимум, то она ''не пригодна'' для использования в реальном времени. Ещё один источник высоких задержек - не оптимизированные для реального времени драйвера оборудования (запрещающие прерывания на долгое время) или само железо (блокирующее процессор на долгое время).


<references />
<references />
{{Category navigation|title=Kernel|category=Kernel|sortkey={{SUBPAGENAME}}}}
{{Category navigation|title=Kernel|category=Kernel|sortkey={{SUBPAGENAME}}}}

Текущая версия от 14:03, 8 сентября 2024

Операционная система реального времени (в отличии от системы общего назначения) оптимизирована на уменьшение задержек реакции (latency) и детерминизм (maximum latency) при обработке событий. Применяется для построения систем в сферах телекоммуникаций, управления машинами, высокочастотной торговли, обработки звука и т.п.[1]

На данный момент в репозиторий Сизиф под архитектуру x86_64 собраны два ядра реального времени:

kernel-image-xenomai

Xenomai.png

"Двойное ядро" состоящее из высокоприоритетного ко-ядра Cobalt реализующего различные (skins) RTOS API Xenomai 3 и ядра линукс с I-Pipe (Adeos) патчем реализующим систему жёсткого реального времени. Xenomai 3 может эмулировать RTOS API: pSOS+, uITRON, VxWorks, RTAI, VRTX, а так же содержит нативное API Alchemy и поддерживает Real-Time Driver Model (RTDM). Документация на англ.

Юзерспейс и специализированные тесты для этого ядра находятся в пакете xenomai.

kernel-image-rt

RealTimeLinux Logo1.png

Real Time Linux с PREEMPT_RT патчем (Ingo Molnar, Thomas Gleixner) реализующим POSIX real-time API. Иногда называемое -rt ядро.

Считается, что ядра данного типа наиболее оптимально работают с vanilla конфигом. Поэтому была использована следующая методология создания конфига: defconfig + все опциональные модули из std_def ядра + тюнинг RT (отключено NO_HZ, отключены многие опции _DEBUG + прочие мелкие оптимизации).

  • Для облегчения тестирования это ядро содержит два дополнительных патча от консорциума OSADL:
  1. https://www.osadl.org/Latency-histograms.latencyhist.0.html
  2. https://www.osadl.org/Precise-load-measurement.precise-system-load.0.html

Для тестирования этого ядра можно использовать пакет linux-rt-tests.

Установка ядра:

# apt-get install update-kernel
# update-kernel -t rt
# reboot

Тестирование ядра

Очень важно первоначально определить пригодность вашей системы для задач реального времени.

cyclictest

Базовый способ тестирования ядра реального времени (POSIX API), это запуск утилиты cyclictest параллельно с созданием нагрузки на систему (генерацию нагрузки вы должны организовать сами, например, запуском unixbench, stress-ng, hackbench, gltestperf в цикле) в течении длительного времени (не менее 24 часов). Пример запуска:

   # cyclictest -a -m -Sp99

Пример вывода на обычном ядре (std_def):

T: 0 ( 1931) P:99 I:1000 C:2018975 Min:      1 Act:    1 Avg:    2 Max:    2151
T: 1 ( 1932) P:99 I:1500 C:1345983 Min:      1 Act:    2 Avg:    3 Max:    2187
T: 2 ( 1933) P:99 I:2000 C:1009488 Min:      1 Act:    1 Avg:    3 Max:    2266
T: 3 ( 1934) P:99 I:2500 C: 807593 Min:      1 Act:    2 Avg:    3 Max:    1886

Для оценки результата следует смотреть на значения Max показывающие время реакции на прерывания в микросекундах. (Есть примеры, на обычной системе, где Max доходит до 5-значных чисел.) Пример вывода на -rt ядре (SMI прерываний не было):

T: 0 ( 4041) P:99 I:1000 C:4719726 Min:      1 Act:    2 Avg:    2 Max:      17
T: 1 ( 4042) P:99 I:1500 C:3146481 Min:      1 Act:    2 Avg:    2 Max:      26
T: 2 ( 4043) P:99 I:2000 C:2359859 Min:      2 Act:    2 Avg:    2 Max:      14
T: 3 ( 4044) P:99 I:2500 C:1887886 Min:      1 Act:    2 Avg:    2 Max:      14

(Есть сообщения, что в некоторых системах Max остается в пределах 1-значного числа.) Пример вывода на -rt ядре при наличии SMI прерываний, cyclictest запущен с дополнительной опцией --smi:

T: 0 (20422) P:99 I:1000 C:305390555 Min:      2 Act:    2 Avg:    3 Max:     297 SMI:     176
T: 1 (20423) P:99 I:1500 C:203593701 Min:      2 Act:    2 Avg:    3 Max:     318 SMI:     176
T: 2 (20424) P:99 I:2000 C:152695274 Min:      2 Act:    2 Avg:    2 Max:     274 SMI:     176
T: 3 (20425) P:99 I:2500 C:122156218 Min:      2 Act:    2 Avg:    3 Max:     340 SMI:     176

Опция --smi добавляет колонку SMI, которая показывает сколько было System Management Interrupts за время теста (счетчик прерываний считывается из MSR, если в вашем процессоре нет такого счетчика, то для их обнаружения можно использовать утилиту hwlatdetect). SMI прерывания могут значительно ухудшить показатели системы. В худшем случае, SMI прерывания способны давать задержки на многие миллисекунды. В системе пригодной для реального времени можно снизить число SMI через настройки или перепрошивку BIOS/firmware[2]. Впрочем, полностью отключать эти прерывания не рекомендуется, так как они выполняют полезные функции для здоровья системы (контроль температуры и прочее). Часто полезно прочитать HPC Tuning Guide[3] для вашего железа. Если задержки в системе превышает требуемый максимум, то она не пригодна для использования в реальном времени. Ещё один источник высоких задержек - не оптимизированные для реального времени драйвера оборудования (запрещающие прерывания на долгое время) или само железо (блокирующее процессор на долгое время).

hwlatdetect

Тест (с помощью hwlat tracer'а ядра) обнаруживает задержки создаваемые железом или firmware не зависимые от ядра, такие как SMI. (Не используйте его на продакшен системах или во время работы других тестов так как принцип его работы - нагружать процессоры на продолжительное время при запрещенных прерываниях, постоянно замеряя время (TSC) и определяя таким образом интервалы с пропусками.) Пример на системе с большими задержками:

# hwlatdetect
hwlatdetect:  test duration 120 seconds
   detector: tracer
   parameters:
        Latency threshold: 10us
        Sample window:     1000000us
        Sample width:      500000us
     Non-sampling period:  500000us
        Output File:       None

Starting test
test finished
Max Latency: 10099000us
Samples recorded: 67
Samples exceeding threshold: 67

rtcheck

Небольшая утилита (от IBM) проверяющая, что запущенное ядро имеет свойства -rt ядра. Запускать с опцией -v для просмотра отчета.

jitterdebugger

Более легкий в использовании аналог cyclictest (от Siemens и SUSE) с уклоном в воспроизводимый статистический анализ. (Домашняя страница. Видео презентация. англ.) Пример запуска:

# jitterdebugger -v

stress-ng

В stress-ng есть свой cyclic стрессор. Удобство, что можно сразу запустить параллельную нагрузку, неудобство, что формат вывода отличается от cyclictest и стрессоры не привязаны к конкретным ядрам, да и запускать больше 1 --cyclic стрессора не рекомендуется (это само по себе создаст избыточную нагрузку на ядро, при этом, почти не даст дополнительной полезной информации).

# stress-ng --cyclic 1 --cyclic-dist 1000 --cyclic-prio 99 --cyclic-sleep 10000 -t 1m