|
| 1 | +Latency Monitoring with Latmon and Latmus |
| 2 | +========================================== |
| 3 | + |
| 4 | +This project provides tools to measure the worst-case response time of a system under test (SUT) to GPIO events using: |
| 5 | + |
| 6 | +- **Latmon**: Runs on a Zephyr-based board to generate and monitor GPIO events while collecting metrics |
| 7 | +- **Latmus**: Runs on the SUT to respond to the falling edge of input GPIO event and display metrics. |
| 8 | + |
| 9 | +This project is part of the open-source initiative `EVL Project - Latmus GPIO Response Time <https://evlproject.org/core/benchmarks/#latmus-gpio-response-time>`_. |
| 10 | + |
| 11 | +Why Not Just Use a Timer? |
| 12 | +------------------------- |
| 13 | +A timer-based test only measures internal response times and often neglects external factors such as GPIO signal propagation, hardware interaction, and interrupt handling. By using Latmon and Latmus, you can simulate real-world hardware-driven scenarios, capturing comprehensive end-to-end latency metrics, including hardware, drivers, and user-space threads. This provides a more accurate assessment of the system's real-time responsiveness. |
| 14 | + |
| 15 | +- **Real-Time Thread Testing**: Evaluates how a user-space thread processes external interrupts. |
| 16 | +- **End-to-End Latency Measurement**: Captures delays from hardware, drivers, and user-space threads. |
| 17 | +- **Versatile Platform Support**: Works on EVL, PREEMPT_RT, and other platforms. |
| 18 | + |
| 19 | +Overview |
| 20 | +-------- |
| 21 | +The main program is designed to monitor latency using GPIO pins on a Zephyr-based system. |
| 22 | +It generates a pulse signal on a GPIO pin and measures the time it takes for the SUT to respond to the signal. |
| 23 | +The SUT must be running Latmus to capture the latency metrics and historgram information reported over the network . |
| 24 | +The program uses LEDS to indicate the different states, such as DHCP binding(red), waiting for the Latmus connection (blue) and sampling (green). |
| 25 | + |
| 26 | +Requirements |
| 27 | +------------ |
| 28 | + |
| 29 | +- **Zephyr-Compatible Board**: A board with external GPIO support (e.g., FRDM-K64F). |
| 30 | +- **SUT**: A system with external GPIO pins running Latmus. |
| 31 | +- **Network Connection**: A DHCP server for IP assignment. |
| 32 | +- **Physical Connection**: GPIO wires connecting the Zephyr board to the SUT. |
| 33 | + |
| 34 | +Setup and Usage |
| 35 | +--------------- |
| 36 | + |
| 37 | +1. Flash Latmon onto the Zephyr board. |
| 38 | +2. Connect GPIO pins for TX (Zephyr to SUT) and RX (SUT to Zephyr). |
| 39 | +3. Run Latmus on the SUT with appropriate options (e.g., ``-p`` for period, ``-g`` for histogram generation). |
| 40 | +4. Monitor results such as min, max, and average latencies. |
| 41 | + |
| 42 | +Example |
| 43 | +------- |
| 44 | + |
| 45 | +Run Latmon and Latmus as follows: |
| 46 | + |
| 47 | + On the host and to flash the Zephyr board:: |
| 48 | + |
| 49 | + $ west flash |
| 50 | + |
| 51 | + On the SUT, latmus **MUST** track the falling edge of the signal:: |
| 52 | + |
| 53 | + $ latmus -I gpiochip2,23,falling-edge -O gpiochip2,21 -z <ip_address> -g "histogram" |
| 54 | + |
| 55 | +On completion, generate a latency histogram on the host (a PNG file) using gnuplot:: |
| 56 | + |
| 57 | + $ gnuplot plot_data.gp |
| 58 | + |
| 59 | +The `plot_data.gp` script should look like this: |
| 60 | + |
| 61 | +.. code-block:: gnuplot |
| 62 | +
|
| 63 | + set terminal pngcairo size 800,600 |
| 64 | + set output 'plot.png' |
| 65 | + set title "Data Plot" |
| 66 | + set xlabel "Latency (usec)" |
| 67 | + set ylabel "Sample Count" |
| 68 | + set grid |
| 69 | + set style data linespoints |
| 70 | + plot 'histogram' using 1:2 with linespoints title "Data Points" |
| 71 | +
|
| 72 | +Contributions |
| 73 | +------------- |
| 74 | + |
| 75 | +Contributions are welcome! Submit a pull request or open an issue. |
| 76 | + |
| 77 | +--- |
| 78 | + |
| 79 | +With Latmon and Latmus, you can evaluate the real-time performance of any system, ensuring it meets stringent real-world application requirements. |
0 commit comments