Тестування затримки

1. Що таке латентність?

Затримка — це час, який потрібен ПК, щоб зупинити поточну роботу і відповісти на зовнішній запит, наприклад, запустити один із періодичних потоків LinuxCNC у режимі реального часу. Чим менша затримка, тим швидше можна запускати потоки у режимі реального часу і тим плавнішим буде рух (а у випадку програмного крокування — ймовірно, швидшим).

Затримка набагато важливіша за швидкість процесора. Непомітний Pentium II, який реагує на переривання протягом 10 мікросекунд кожного разу, може дати кращі результати, ніж найновіший і найшвидший P4 Hyperthreading.

Процесор не є єдиним фактором, що впливає на затримку. Материнські плати, відеокарти, USB-порти та ряд інших факторів також можуть впливати на затримку. Найкращий спосіб з’ясувати, з чим ви маєте справу, — це провести тест на затримку.

Generating step pulses in software has one very big advantage - it’s free. Just about every PC that has a parallel port is capable of outputting step pulses that are generated by the software.

However, software step pulses also have some disadvantages:

обмежена максимальна швидкість кроку
тремтіння у згенерованих імпульсах
завантажує процесор

2. Тести на затримку

LinuxCNC містить кілька тестів затримки. Усі вони надають еквівалентну інформацію. Виконання цих тестів допоможе визначити, чи підходить комп’ютер для керування верстатом з CNC.

Note	Не запускайте LinuxCNC або StepConf під час виконання тесту затримки.

2.1. Тест на затримку

The latency test can be run a few different ways.

If you are using PnCconf to configure your machine, you can launch the Latency Test by clicking the "Test Base Period Jitter button' during the 2nd step of the process.

If you are using StepConf to configure your machine, you can launch the Latency Test by clicking the "Test Base Period Jitter button' during the 2nd step of the process.

If you want to run the test from the command line, open a terminal window (in Ubuntu, from Applications → Accessories → Terminal) and run the following command:

latency-test

Це розпочне тест затримки з періодом базового потоку 25 мкс та періодом сервопотоку 1 мс. Періоди можна вказати в командному рядку:

latency-test 50000 1000000

Це розпочне тест затримки з періодом базового потоку 50 мкс та періодом сервопотоку 1 мс.

Щоб переглянути доступні опції, у командному рядку введіть:

latency-test -h

Після запуску тесту затримки ви повинні побачити щось подібне:

Figure 1. Тест затримки HAL

Під час виконання тесту слід «зловживати» комп’ютером. Переміщайте вікна по екрану. Переглядайте веб-сторінки. Копіюйте великі файли на диск. Відтворюйте музику. Запустіть програму OpenGL, наприклад glxgears. Ідея полягає в тому, щоб випробувати ПК на міцність, поки тест на затримку перевіряє, які показники є найгіршими.

Важливим числом для крокування програмного забезпечення є «максимальний джиттер» базового потоку. У наведеному вище прикладі це 6693 наносекунди (нс) або 6,693 мікросекунди (мкс). Запишіть це число і введіть його в StepConf, коли буде запропоновано.

In the example above, latency-test only ran for a few seconds. You should run the test for at least several minutes; sometimes the worst case latency doesn’t happen very often, or only happens when you do some particular action. For instance, one Intel motherboard worked pretty well most of the time, but every 64 seconds it had a very bad 300 µs latency. Fortunately that was fixable, see [_latency_tuning].

So, what do the results mean?

If your Max Jitter number is less than about 20,000 nanoseconds, the computer should give very nice results with software stepping or a dedicated hardware card such as a Mesa Anything I/O card.

If the Max Jitter number is between 20,000 and 50,000 nanoseconds, you can still get good results with software stepping, but your maximum step rate might be a little disappointing, especially if you use microstepping or have very fine pitch leadscrews. You can, however, achieve excellent results using a hardware card.

If the Max Jitter number is between 50,000 and 500,000 nanoseconds, you cannot use software stepping. You can, however, achieve acceptable results using a hardware card.

If the Max Jitter number is above 500,000 nanoseconds, you cannot use software stepping or a hardware card with LinuxCNC and achieve acceptable results.

Note	If you get high numbers, there may be ways to improve them. Another PC had very bad latency (several million nanoseconds) when using the onboard video. But a $5 used video card solved the problem. LinuxCNC does not require bleeding-edge hardware.

Для отримання додаткової інформації про налаштування крокового двигуна див. розділ Налаштування крокового двигуна.

Tip	Додаткові інструменти командного рядка доступні для перевірки затримки, коли LinuxCNC не запущено.

2.2. Графік затримки

latency-plot створює стрічкову діаграму для базового та серво-потокового потоків. Може бути корисним побачити піки затримки під час запуску або використання інших програм. Використання:

latency-plot --help

Використання:
      latency-plot --help | -?
      latency-plot --hal [Options]

Параметри:
      --base ns  (базовий інтервал потоку в наносекундах, за замовчуванням:   25000)
      --servo ns (інтервал сервопотоку в наносекундах, за замовчуванням: 1000000)
      --time ms  (інтервал звітування в мілісекундах, за замовчуванням: 1000)
      --relative (відносний час за годинником (за замовчуванням))
      --actual   (фактичний час за годинником)

Figure 2. latency-plot Вікно

2.3. Гістограма затримки

Гістограма затримки застосунку відображає гістограму затримки (тремтіння) для базового та серво-потоків.

Використання:
   latency-histogram --help | -?
   latency-histogram [Options]

Опції:
  --base      ns   (базовий інтервал потоку в наносекундах, за замовчуванням:   25000, мінімум:  5000)
  --servo     ns   (інтервал сервопотоку в наносекундах, за замовчуванням: 1000000, мінімум: 25000)
  --bbinsize  ns   (базовий розмір біна в наносекундах, за замовчуванням: 100
  --sbinsize  ns   (розмір сервобіна в наносекундах, за замовчуванням: 100
  --bbins     n    (базові  біни, за замовчуванням: 200
  --sbins     n    (сервобіни, за замовчуванням: 200
  --logscale  0|1  (логарифмічна шкала осі Y, за замовчуванням: 1)
  --text      note (додаткова примітка, за замовчуванням: "" )
  --show           (показати кількість не відображених бінів)
  --nobase         (тільки серво-потік)
  --verbose        (прогрес і налагодження)
  --nox            (без графічного інтерфейсу, відображення elapsed,min,max,sdev для кожного потоку)

Note

When determining the latency, LinuxCNC and HAL should not be running, stop with halrun -U. Large number of bins and/or small binsizes will slow updates. For single thread, specify --nobase (and options for servo thread). Measured latencies outside the +/- bin range are reported with special end bars. Use --show to show count for the off-chart [pos|neg] bin.

Figure 3. latency-histogram Вікно

2.4. Realtime status bar

The latency-test and latency-histogram windows show a status bar along the bottom with three fields. A field turns red when it indicates a condition that makes the measured latency unrepresentative of a properly configured realtime system.

У режимі реального часу: The realtime type that rtapi is running, as reported by realtime verify, for example Preempt RT, RTAI or Xenomai. It reads No realtime (red) when rtapi_app cannot obtain realtime scheduling, either because the running kernel is not a realtime kernel (see Kernel and Version requirements) or because rtapi_app lacks the required privileges on a run-in-place build (see Realtime, run sudo make setuid or sudo make setcap). In this state the figures reflect ordinary, non-realtime scheduling and will be far worse than a realtime kernel delivers. For testing only, realtime can be forced with the LINUXCNC_FORCE_REALTIME=1 environment variable.
CPU governor: The active CPU frequency governor. It is shown in red when it is not performance, because frequency scaling lets the CPU drop to a lower clock speed and adds latency spikes. See CPU frequency governor.
isolcpus: Whether any CPUs are isolated for the exclusive use of LinuxCNC (isolcpus=...) or not (no_isolcpus). Isolating a CPU keeps other tasks off it and improves latency; see Tuning Preempt-RT for latency.

3. Налаштування затримки

LinuxCNC може працювати на багатьох різних апаратних платформах та з багатьма різними ядрами реального часу, і всі вони можуть отримати користь від налаштування для оптимальної затримки.

Основною метою налаштування системи для LinuxCNC є резервування процесора для виключного використання завданнями LinuxCNC в режимі реального часу, щоб інші завдання (як програми користувачів, так і потоки ядра) не перешкоджали доступу LinuxCNC до цього процесора.

Якщо певні параметри налаштування вважаються загальнокорисними, LinuxCNC виконує це налаштування автоматично під час запуску, але багато параметрів налаштування є специфічними для конкретної машини і не можуть бути виконані автоматично. Особа, яка встановлює LinuxCNC, повинна експериментальним шляхом визначити оптимальні параметри налаштування для своєї системи.

3.1. Налаштування BIOS для зменшення затримки

BIOS ПК дуже різняться за своєю затримкою.

Налаштування BIOS є досить трудомістким процесом, оскільки вам доведеться перезавантажувати комп’ютер, вносити невеликі зміни в BIOS, завантажувати Linux і виконувати тест затримки (що може зайняти багато часу), щоб побачити, як зміни в BIOS вплинули на роботу системи. Потім повторіть ці дії для всіх інших налаштувань BIOS, які ви хочете випробувати.

Оскільки всі BIOS різні та нестандартні, надання детального посібника з налаштування BIOS не є практичним. Загалом, деякі речі, які можна спробувати налаштувати в BIOS:

Вимкніть ACPI, APM та будь-які інші функції енергозбереження. Це включає все, що пов’язано з енергозбереженням, призупиненням, станами сну процесора, масштабуванням частоти процесора тощо.
Вимкніть режим "турбо" процесора.
Вимкнути гіперпоточність процесора.
Вимкнути (або іншим чином керувати) перериваннями системного керування (SMI).
Вимкніть будь-яке обладнання, яке ви не збираєтеся використовувати.

3.2. CPU frequency governor

Frequency scaling lets the CPU lower its clock speed to save power, which adds latency while the CPU ramps back up to service a realtime thread. For the best latency, set the governor to performance on every CPU:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

This setting does not survive a reboot. To make it permanent, apply it at boot with a small systemd service, or with a CPU frequency management tool such as cpupower (Debian/Ubuntu package linux-cpupower) or tuned.

3.3. Налаштування Preempt-RT на затримку

Ядро Preempt-RT може отримати користь від налаштування, щоб забезпечити найкращу затримку для LinuxCNC. Налаштування можна виконати через командний рядок ядра, sysctl, та через файли в /proc та /sys.

Деякі параметри налаштування, на які варто звернути увагу:

Командний рядок ядра

Деталі тут: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt

isolcpus: Запобігти використанню цих процесорів більшістю процесів, що не належать до LinuxCNC, залишаючи більше процесорного часу доступним для LinuxCNC.
irqaffinity: Виберіть, які процесори обслуговують переривання, щоб процесори, зарезервовані для роботи в реальному часі LinuxCNC, не виконували це завдання.
rcu_nocbs: Запобігти виконанню зворотних викликів RCU на цих процесорах.
rcu_nocb_poll: Опитувати зворотні виклики RCU замість використання режиму сну/пробудження.
nohz_full: Вимкніть тактування на цих процесорах.

Sysctl

Деталі тут: https://www.kernel.org/doc/html/latest/scheduler/sched-rt-group.html

sysctl.kernel.sched_rt_runtime_us: Встановіть значення -1, щоб зняти обмеження на час, який можуть використовувати завдання в реальному часі.