realtime:documentation:howto:debugging:cyclictest:test-design:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
realtime:documentation:howto:debugging:cyclictest:test-design:start [2018/08/06 13:18] ebugden [Cyclictest - Test Design] Specify that the load is also important |
realtime:documentation:howto:debugging:cyclictest:test-design:start [2018/08/06 13:23] ebugden [System Load] Add link to worst case latency test setup examples |
||
|---|---|---|---|
| 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. 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 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. |
| 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. | ||
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
