Column: Embedded design


implemented as well. When we zoom out of the trace,


there’s a flurry of execution instances of the eth0 interrupt handler executing around the same time as the iperf experiment, and we can conclude that there is a correlation between when the eth0 interrupt handler executes and when the iperf instance executes; see Figure 4. Zooming in to the middle of the trace


Figure 6: The time between eth0 IRQ handler completing its execution and the start of the iperf execution


of Figure 4 to assess the throughput measurement (and avoid the distraction of any protocol-specific exchange between the perf server and client), a pattern appears; see Figure 5. Zooming into the trace even


further, and measuring the interval between when the eth0 IRQ handler has completed execution and the start of the iperf execution, we see that it is approximately 55 microseconds; see Figure 6. Clicking on that particular iperf


execution instance and then on the “+” next to the “Instance” in the Selection Details view, it can be seen that this particular instance of iperf is executing on CPU3 as expected; see Figure 7. As a baseline, we now know it takes


Figure 7: Confi rmation that the particular instance of iperf is executing on CPU3


Then, I run an iperf test from the host machine, and then stop lttng and destroy the session to avoid having large traces with extraneous events.


$> lttng stop $> lttng destroy


There are a few interesting results in the capture when iperf is pinned to CPU3. First, there are four instances of the iperf process running, even though Linux listed only a single instance. Next, the instance of iperf that corresponds to the PID reported by Linux executes only


10 April 2021 www.electronicsworld.co.uk


twice: once at the beginning of the iperf measurement and again at the end; see Figure 2. We can also see that even though


we instructed iperf to be pinned to CPU3, there are other instances of iperf executing on different CPU cores; see Figure 3. Although I instructed iperf to limit its


execution to CPU3, something caused it to run on other CPUs. This is not so uncommon, since applications can implement their own logic for selecting the appropriate CPU for execution. It appears that iperf has similar logic


55 microseconds from completion of the eth0 interrupt handler to when the iperf instance begins execution. Now I’ll put the system under load, by executing the following command on the terminal of the Jetson Nano, which runs twenty processes across all the CPUs:


$> stress --cpu 20 The output of the top command in


Figure 8 shows that all four cores are being throttled to their maximum. Performing a new iperf measurement


shows that the throughput is still 851Mbps:


$> iperf -b1G -c 192.168.2.247 -p5001 [ 3] 0.0-10.0 sec 1.10 GBytes 851 Mbits/sec


Let’s open Tracealyzer with a capture taken when I artificially stressed the


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44