Part Number: AM6442
Tool/software:
4.2.2.3.1. Timer Based Applications
Say for example you need to take a measurement from a sensor every 100us for quality assurance. So our application will wake a task up every 100us to take this measurement before sending it out to the main controller. This being a timer based task, we will need to ensure the kernel has a periodic interrupt generated fast enough to ensure the kernel can switch to our task to take a sample at our 100us deadline.
To simulate this type of workload we can generate various background loads that our application may experience using a tool like stress-ng.
stress-ng –cpu-method=all -c20 &
Then we can monitor our application’s performance or use another tool like cyclictest to measure the context switch latency the CPUs are experiencing.
Cyclictest is a simple program maintained by the real-time kernel developers to detect any anomolies or latency spikes when developing the next version of the Linux kernel. There are quite a few options we can set however for this example we will run cyclictest on all CPU cores with a priority of 80 for 5 hours.
cyclictest -m -Sp80 -D5h -h400 -i200 -M
...
# Total: 108000000 107999945 107999881 107999811
# Min Latencies: 00003 00004 00003 00003
# Avg Latencies: 00005 00005 00005 00005
# Max Latencies: 00029 00033 00034 00037
Here we can see each CPU took on average 5us however they took a maximum of 29us, 33us, 34us and 37us to switch from the background stress-ng tasks to the cyclictest task which was measuring the context switch. Though this may be of little relevance if your application is doing more than only consuming CPU cycles.
Depending on the usecase it may be more suitable to run different or more stressing algorithms than just a CPU stressing function for example a function to stress the memory-management system. More information and a complete list about these functions in stress-ng can be found in the source code of this project located here: https://github.com/ColinIanKing/stress-ng
4.2.2.3.2. Driver (Ethernet) Based Interrupts
As we will see a little later, a lot of work has gone into servicing IO or hard interrupts by our CPUs in the real-time kernel. And while a large portion of these interrupt handlers have been offloaded to threaded interrupts which can be put to sleep, these smaller hard interrupts are not completely transparent and continue to degrade performance.
One good way to demonstrate this is by using the iperf3 tool to generate large amounts of ethernet traffic.
On a host machine connected to our embedded device we can run the following command to create a server to listen for incoming network traffic
iperf3 -s
Next, on our embedded device, we can issue the command to send ethernet traffic back and forth to the server to generate large amounts of hard interrupts for our CPUs to service the incoming packets
iperf3 -c 10.10.10.1 -p 7575 -bidir
With this going on in the background, we can begin monitoring our application or using cyclictest again to show that the maximum latencies have increased and depending on your use case may even exceed our requirements for our application.
I am using the AM6442 chip with version 10.01. For interrupt latency testing on a Debian-based RTOS, besides the two methods mentioned above, are there any other ways to measure interrupt latency? I want to test its interrupt latency to compare its real-time performance with other systems.
