Changes

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

min: 666 393 ns (44 26 ticks) avg: 696 409 ns (46 27 ticks) max: 2075 681 ns (137 45 ticks)

total samples: 11941592

 This application is extremely useful for evaluating characterizing how interrupt latency is affected depending on the CPU load on the first core and other parameters (memory bandwidth utilization, number of interrupts to be processed by the first core affects IRQ , operating frequency, etc.).For instance, the previous data refer to the following configuration:*governor: <code>userspace</code>*nominal operating frequency: 800 MHz (actual: 792 MHz)*core #0 (running Linux) lightly loaded. 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.