{{WarningMessage|text=This application note was validated against specific versions of the kit only. It may not work with other versions. Supported versions are listed in the ''History'' section.}}
|Added some details about <code>latencystat</code> test application
|}
The resulting binary must be copied from the building directory to the root file system, e.g. on the <code>/home/root</code> directory of the root-file system.
=== Running the AMP example application on the target ===
As stated before, this example shows a sophisticated approach that allows for:
* using a standardized communication channel between the two cores
Bucket 666 393 ns (44 26 ticks) had 135 1 frequency Bucket 681 409 ns (45 27 ticks) had 204 475 frequency Bucket 696 424 ns (46 28 ticks) had 335 1058 frequency Bucket 712 439 ns (47 29 ticks) had 371 57 frequency Bucket 727 681 ns (48 ticks) had 66 frequency Bucket 742 ns (49 ticks) had 81 frequency Bucket 757 ns (50 ticks) had 1 frequency Bucket 2075 ns (137 45 ticks) had 1 frequency
This application is extremely useful for evaluating measuring interrupt latency and for verifying how it is affected by relevant parameters such as the CPU load on the first core, memory bandwidth utilization, the amount/rate of interrupts to be processed by the first core affects IRQ , operating frequency, etc. For instance, the previous data refer to the following configuration:*[[FAQs_(Axel)#Q:_How_can_I_change_the_CPU_clock_frequency.3F|governor]]: <code>userspace</code>*nominal operating frequency: 800 MHz (actual: 792 MHz)*core #0 (running Linux) lightly loaded with minimal I/O activity. In general, it is strongly recommended to characterize the latencyon the basis of a '''realistic testbed that is as close as possible to the actual use case'''. In It is also worth remembering that, in case of latency does not satisfy the application's real-time requirements, it may be necessary is possible to adjust the arbitration priorities of processor's interconnect subsystemto reduce it.