OST » Wikis » Infoportal Sie befinden sich hier: start » software » linux » realtime » benchmark » benchmark

Infoportal

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
software:linux:realtime:benchmark:start [2019-02-08 15:26] – mgehrig2software: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. Standard tool to measure the maximum jitter of a system.
  
-[[software:linux:realtime:benchmark:cyclictest|**Cyclictest**]]+**[[..:cyclictest|Cyclictest]]** 
 + 
 + 
 + 
 +===== Influences on real-time behaviour ===== 
 +The following things can influence the real-time behaviour: 
 + 
 +  * CPU 
 +    * 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 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.
  
  

Seiten-Werkzeuge

OST - Ostschweizer Fachhochschule - Campus Buchs
Uebersicht