Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- software:linux:realtime:benchmark:start [2019-02-08 15:41] – mgehrig2
+++ software:linux:realtime:benchmark:start [2023-04-11 11:16] – Urs Graf
@@ Zeile 9: / Zeile 9: @@
 Standard tool to measure the maximum jitter of a system.
-**[[software:linux:realtime:benchmark:cyclictest|Cyclictest]]**
+**[[..:cyclictest|Cyclictest]]**
@@ Zeile 17: / Zeile 17: @@
   * CPU
-    * Mobile x86 CPU (with suffix like U, Y and M i.e i7-4600U) seems to performe worse
+    * Mobile x86 CPU (with suffix like U, Y and M i.e i7-4600U) seems to perform much worse than non-mobile processors. Mobile processer add about 100us-200us jitter.
-    * arm
+    * ARM processer seem to have about 60us max jitter and a high medium jitter
   * Kernel version
     * 4.4.169-rt177 seems to be better than 4.19.15-rt12
+  * BIOS settings
+  * Some drivers, like WiFi driver, may negatively influence latency
+==== Don't ====
+  * Don't start the application 'Grub customizer' while a real-time application is running. This can introduce latencies of more than 4msec.
+==== Does ====
+  * You should remove as many of the unknowns as possible. This means that only the necessary drivers should be loaded.
+  * If possible, use only a text based system. See '[[software:linux:linux_os:text_only:start|Boot Ubuntu in text mode]]'.
+  * Run only software that is absolutely necessary on the real-time master.
+  * Deactivate automatic updates.
+  * A stable system can only be guaranteed if it has been sufficiently tested. Each system is different and must be tested.
 ===== Methodical procedure =====
+==== Overview ====
+At first, test the most basic system possible.
+With this test, you can get a baseline of the best possible real-time performance of the hardware.
+Every feature added will make the system more complex and add more stuff, which can increase jitter.
+With this approach you can get a feeling which performance is possible and which part of the system is responsible for a high jitter.
+  - Test hardware, BIOS settings and kernel version
+  - Test full distro in text mode
+  - Test full distro in graphical mode
+  - Test full distro under load
+==== 1.) Test hardware, BIOS settings and kernel version ====
+  - Build a [[software:linux:realtime:preempt_rt:build_kernel|RT-kernel]] and install it.
+  - Install the [[software:linux:realtime:benchmark:cyclictest|cyclictest]]
+  - Reboot with the new kernel in [[software:linux:linux_os:run_lvl_1|RunLevel 1]]
+  - Check the real-time performance with [[software:linux:realtime:benchmark:cyclictest|cyclictest]]
+**Tipp**: You may want to use [[https://wiki.archlinux.org/index.php/GNU_Screen |screen]].
+This application provides multiple virtual terminal sessions if you want to run multiple programs in parallel..
+=== Tuning ===
+If you the measured latencies are to high, you can tweak your system.
+The options which are simple but effective are listed first.
+  * Tune some [[software:linux:realtime:tune_bios_settings|BIOS settings]]
+  * Use a different kernel version. (4.4.169-rt177 seems to be better than 4.19.15-rt12)
+  * Tune some kernel settings TODO
+  * If the jitter is still too high, you may have to choose a different CPU
+==== 2.) Test full distro in text mode ====
+Boot your system in [[software:linux:linux_os:text_only:start|text mode]].
+If the real-time performance is not significantly reduced, then the third step can be continued.
+Run a 24h test so that exceptional events can also be detected.
+If the real-time performance is significantly worse, then a WLAN driver or something similar can be the cause.
+To further isolate the problem, the WLAN driver, or another suspected driver, can be deactivated (''rmmod iwlwifi'').
+A new test should result in an improvement of the maximum jitter.
+=== Other possible causes ===
+  * WLAN driver
+  * Ethernet driver
+  * Bluetooth driver
+  * Various peripheral devices
+==== 3.) Test full distro in graphical mode ====
+It is recommended that a real-time system be used only in text mode.
+With a graphical user interface, the system is generally more unstable.
+If, however, the system is to be used with a graphical user interface, a 24h test [[software:linux:linux_os:text_only:start|including a graphical user interface]] is recommended.
+==== 4.) Test full distro under load ====
+=== High CPU load ===
+High CPU load from non-RT processes does not affect the performance of RT processes very much.
+However, if the processor is not sufficiently cooled (e.g. in a mobile system), the processor can overheat.
+In such a case, the processor clock is clocked down by the system, which can severely impair real-time performance.
+Check the temperature of the CPU under high load with [[https://wiki.archlinux.org/index.php/lm_sensors | lmsensors]] to avoid this problem.
+If the processor does overheat:
+  * Disable hyper.threading in BIOS
+  * Deactivate Turboboost in BIOS
+  * Ensure better cooling
+**Note ***: Depending on the processor, //lm_sensors// itself may cause high latency.
+Observe the //Cyclictest// during the ''sensor'' call to check this.
+=== Normal Load ===
+In the last test allplitkation are to be started, which are to run also later in the employment.
+For the //cyclictest// to measure correctly, its priority must be one higher than the priority of the RT application.
+This test should last at least 24 hours.

Infoportal

Infoportal

Unterschiede

Infoportal

Infoportal

Unterschiede

Seiten-Werkzeuge