Difference between revisions of "Pma tools/jitter"
(Initial publication of jitter BKM) |
|||
| Line 1: | Line 1: | ||
| − | |||
| − | Jitter | + | == Definition == |
| + | Jitter in execution can happen because of underline hardware or OS interferences. These interferences take out cycles from real-time applications such as packet processing workloads. | ||
| − | + | == Jitter implication on packet processing == | |
| + | Packet processing workloads need to account for maximum jitter. When CPU is not perform packet processing due to hardware or OS interferences, the system needs to buffer the packets. When jitter is excessive, the system may run out of buffers and starting to drop packets. | ||
| − | + | == Build and Execution == | |
| + | To build the jitter program, simply clone the pma_tools repo and run make command in jitter folder. | ||
| + | To run the jitter program, first check the intended core is idle, and use taskset to pin jitter program on the idle core. (i.e. taskset -c 2 ./jitter) | ||
| + | == Measurement and Analysis == | ||
| + | This benchmark measures variation in execution for a userspace dummy loop repeatedly to indicate jitter in the platform. | ||
| + | If Inst_Jitter column from jitter program is reporting >10,000 cycles, user may want to optimize hardware/OS to minimize this value. | ||
| − | + | == Jitter test program overview == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Jitter test program overview | + | |
Jitter test program simulated an userspace program in a tightly polling loop (like DPDK). It wants to execute a piece of code continuously with minimal interruption from OS or other userspace processes. | Jitter test program simulated an userspace program in a tightly polling loop (like DPDK). It wants to execute a piece of code continuously with minimal interruption from OS or other userspace processes. | ||
| Line 27: | Line 23: | ||
Jitter test program executes a simple arithmetic operations (dummyop) in a loop (~80000). Measure rdtsc (cycles) for the loop execution time. If there is no OS/process interference, it should take fix amount of time to execute these loops every time. Currently, in 20,000 samples interval (each sample is 80,000 dummyop), the jitter varies from 5K cycles to 70K cycles. The goal is to keep it under control under 10K at all time. | Jitter test program executes a simple arithmetic operations (dummyop) in a loop (~80000). Measure rdtsc (cycles) for the loop execution time. If there is no OS/process interference, it should take fix amount of time to execute these loops every time. Currently, in 20,000 samples interval (each sample is 80,000 dummyop), the jitter varies from 5K cycles to 70K cycles. The goal is to keep it under control under 10K at all time. | ||
| − | + | == Reference results == | |
| − | + | [[File:jitter_reference_output.jpg]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 22:36, 19 December 2017
Contents
Definition
Jitter in execution can happen because of underline hardware or OS interferences. These interferences take out cycles from real-time applications such as packet processing workloads.
Jitter implication on packet processing
Packet processing workloads need to account for maximum jitter. When CPU is not perform packet processing due to hardware or OS interferences, the system needs to buffer the packets. When jitter is excessive, the system may run out of buffers and starting to drop packets.
Build and Execution
To build the jitter program, simply clone the pma_tools repo and run make command in jitter folder.
To run the jitter program, first check the intended core is idle, and use taskset to pin jitter program on the idle core. (i.e. taskset -c 2 ./jitter)
Measurement and Analysis
This benchmark measures variation in execution for a userspace dummy loop repeatedly to indicate jitter in the platform.
If Inst_Jitter column from jitter program is reporting >10,000 cycles, user may want to optimize hardware/OS to minimize this value.
Jitter test program overview
Jitter test program simulated an userspace program in a tightly polling loop (like DPDK). It wants to execute a piece of code continuously with minimal interruption from OS or other userspace processes.
Jitter test program executes a simple arithmetic operations (dummyop) in a loop (~80000). Measure rdtsc (cycles) for the loop execution time. If there is no OS/process interference, it should take fix amount of time to execute these loops every time. Currently, in 20,000 samples interval (each sample is 80,000 dummyop), the jitter varies from 5K cycles to 70K cycles. The goal is to keep it under control under 10K at all time.
Reference results
