Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Characterization and performance tests
Some basics tests have been conducted to characterize the system configured as described above. The figure the tests focus on is the interrupt latency on W1 realm. This value has been measured under different system load conditions to verify if and how the non real-time world may influence the real-time world.
** idle
** Google stressapptest <ref name="SAT">https://code.google.com/p/stressapptest/"</ref>, stressing running to stress SDRAM memory and SD I/O.* About RTOS side:
** idle
** memory intensive task; two subcases, in turn, have been considered to evaluate the impact of the L2 cache unavailability.
The RTOS memory task access an array in main memory of two different sizesizes:
* the smaller is half of L1 size (16KiB)
* the larger is 4 times the L1 size(128KiB)
The main task on the RTOS side is the ''latencystat'' demo provided with [[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|AN-BELK-001]]<ref name="AN-BELK-001"></ref>, which:
* program programs PS TTC timer as freerun, triggering an interrupt on overflow* inside the overflow ISR it read the TTC counteris read: this counter reports the number of ticks passed elapsed between the event (overflow) and the handler itself, in other words our the interrupt latency* after a while the TTC is reprogrammed and interrupt is enabled again, to trigger another event* those ''latency countercounters'' are collected into an array* the Linux-side application, by default after 10 seconds, stop stops the RTOS task which sends the array data over RPMSRPMsg* the Linux-side application collect collects the data and display the mininum, maximum and average latency measured
The following table summarize the test results (all timing are given in ''ns'')
| max || align="right"| 548 || align="right"| 539 || align="right"| 575 || align="right"| 3050
|}
==Conclusions and future work==
