User Tools

Site Tools


realtime:documentation:howto:tools:cyclictest:test-design

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
realtime:documentation:howto:tools:cyclictest:test-design [2018/08/21 12:47]
ebugden [Option Selection] Update link
realtime:documentation:howto:tools:cyclictest:test-design [2021/12/02 17:48] (current)
bartwensley [Option Selection]
Line 14: Line 14:
 The best way to measure the latencies that an RT application would experience on a specific system is to run the actual RT application on the platform along with Cyclictest and any other non-RT application that would normally be running as well. This method has its disadvantages. For example, if the applications cause system latencies very infrequently then it could take a very long time for Cyclictest to notice them. The best way to measure the latencies that an RT application would experience on a specific system is to run the actual RT application on the platform along with Cyclictest and any other non-RT application that would normally be running as well. This method has its disadvantages. For example, if the applications cause system latencies very infrequently then it could take a very long time for Cyclictest to notice them.
  
-Another solution is to simulate the load generated by the final application. This can be done using a tool like Hackbench (available in the [[realtime:​documentation:​howto:​tools:​rt-tests|rt-tests]] suite). Ideally, the simulation should be as close as possible to the final application in all respects including CPU use, memory use, I/O, number of tasks, network use, etc. Examples of how to generate different loads for testing real-time systems can be found [[realtime:​documentation:​howto:​tools:​worstcaselatency|here]]. However, even if the application is simulated correctly it is possible that an artificial load would not trigger system latencies that the final application would trigger. In this case, the Cyclictest results might not reflect the real maximum latencies that the application would experience. Accurately simulating the load that an application will apply on a system tends to be very complex and difficult, so running a simulated load that stresses the system more than the application is predicted to stress it is often done instead.+Another solution is to simulate the load generated by the final application. This can be partially ​done using a tool like [[realtime:​documentation:​howto:​tools:​hackbench|Hackbench]] (available in the [[realtime:​documentation:​howto:​tools:​rt-tests|rt-tests]] suite). Ideally, the simulation should be as close as possible to the final application in all respects including CPU use, memory use, I/O, number of tasks, network use, etc. Examples of how to generate different loads for testing real-time systems can be found [[realtime:​documentation:​howto:​tools:​worstcaselatency|here]]. However, even if the application is simulated correctly it is possible that an artificial load would not trigger system latencies that the final application would trigger. In this case, the Cyclictest results might not reflect the real maximum latencies that the application would experience. Accurately simulating the load that an application will apply on a system tends to be very complex and difficult, so running a simulated load that stresses the system more than the application is predicted to stress it is often done instead.
  
 In the end, it can be valuable to run tests using both techniques. If some tests are run using an artificial load and some tests are run using the real applications as the load, then there is a better chance of detecting all the possible latencies that the RT application could experience. In the end, it can be valuable to run tests using both techniques. If some tests are run using an artificial load and some tests are run using the real applications as the load, then there is a better chance of detecting all the possible latencies that the RT application could experience.
Line 23: Line 23:
  
 Here is a list of options that should always be considered when measuring latencies with Cyclictest: Here is a list of options that should always be considered when measuring latencies with Cyclictest:
-  * [[realtime:​documentation:​howto:​debugging:​cyclictest:​test-design:​threads|Number and affinity of measuring threads]] (--threads, --affinity)+  * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​threads|Number and affinity of measuring threads]] (--threads, --affinity)
   * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​interval|Thread wake-up interval]] (--interval,​ --distance)   * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​interval|Thread wake-up interval]] (--interval,​ --distance)
   * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​priority|Thread real-time priority]] (--priority)   * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​priority|Thread real-time priority]] (--priority)
   * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​duration|Test duration]]   * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​duration|Test duration]]
-  * Prevent Cyclictest pages from being paged out of memory (--mlockall+  * [[realtime:​documentation:​howto:​tools:​cyclictest:​options:​mlockall|Prevent Cyclictest pages from being paged out of memory]] (--mlockall)
-  * Use clock_nanosleep for high-resolution thread sleeping with a faster expiry path than POSIX interval timers (--nanosleep)+
  
-Using the --mlockall option, which prevents Cyclictest pages from being paged out, reduces the Cyclictest overhead by avoiding having to reload pages from the disk. +When running Cyclictest on a symmetric ​multi-processing (SMP) system, specifying the --smp option can be useful as it takes care of some of the options mentioned above without having to specify them all individually.
- +
-The POSIX interval timers are signal based and their expiry path is slow because it goes through the hrtimer softirq. On the other hand nanosleep has a much less expensive expiry path because it is just a wakeup.  +
- +
-When running Cyclictest on a symmetic ​multi-processing (SMP) system, specifying the --smp option can be useful as it takes care of some of the options mentioned above without having to specify them all individually.+
  
 ===== Observer Effect ===== ===== Observer Effect =====
  
 When designing a test, it is important to minimize the effect that running Cyclictest could have on the latencies that are being observed in a system. For example, when measuring the latencies on a specific CPU, make sure that the main Cyclictest thread is not running on that CPU, otherwise the additional context switches will influence the latencies that are measured. A technique for doing this is presented on the [[realtime:​documentation:​howto:​tools:​cyclictest:​faq#​how-can-the-influence-of-cyclictest-be-minimized-when-evaluating-latencies-on-an-isolated-set-of-cpus|Cyclictest FAQ]]. When designing a test, it is important to minimize the effect that running Cyclictest could have on the latencies that are being observed in a system. For example, when measuring the latencies on a specific CPU, make sure that the main Cyclictest thread is not running on that CPU, otherwise the additional context switches will influence the latencies that are measured. A technique for doing this is presented on the [[realtime:​documentation:​howto:​tools:​cyclictest:​faq#​how-can-the-influence-of-cyclictest-be-minimized-when-evaluating-latencies-on-an-isolated-set-of-cpus|Cyclictest FAQ]].
realtime/documentation/howto/tools/cyclictest/test-design.1534855656.txt.gz · Last modified: 2018/08/21 12:47 by ebugden