Measured worst-case execution time
KideRT records the longest time each system call took on a target. This page shows those figures for its most common POSIX calls, in CPU cycles and microseconds. Each figure is the longest time the measurement observed, not a proven worst case. O(1) means the worst-case time of a call does not grow with the application. The figures give that time for this target.
| Call | Cycles | µs |
|---|---|---|
| pthread_create | 2,512 | 39.25 |
| pthread_mutex_lock | 2,308 | 36.06 |
| pthread_mutex_unlock | 552 | 8.63 |
| sem_wait | 2,222 | 34.72 |
| sem_post | 372 | 5.81 |
| mq_send | 2,251 | 35.17 |
| mq_receive | 2,243 | 35.05 |
| timer_settime | 2,537 | 39.64 |
| clock_gettime | 619 | 9.67 |
| Context switch | 52 | 0.81 |
| Interrupts masked | 128 | 2.00 |
Each figure is the longest time observed in the measurement, not a proven worst case.
Measurement conditions
Every figure depends on the target and the build. These are the conditions of the measurement. On another core, clock or build the figures differ, so measure on yours.
- Core
- Arm Cortex-M3
- Clock
- 64 MHz
- Compiler and version
- Arm GNU Toolchain 13.2.Rel1 (GCC 13.2.1)
- Optimisation level
- -O2
- Caches
- None
- KideRT version
- —
- Build options
- Memory protection off
Reading the figures
KideRT measures its own timing. With the instrumentation enabled, the kernel records the longest time each system call took on the target, and the report gives it in CPU cycles.
Read about O(1) system calls- Longest observed
- Each figure is the longest time the call took in three runs of a workload that exercises every call, with 1 to 16 threads, timers, waiters and queued messages. It is the maximum those runs observed, not a proven worst case.
- Blocking calls
- For a call that blocks, such as sem_wait or mq_receive, the figure is the time the call takes in the kernel, not the time the thread waits.
- Interrupts
- An interrupt that arrives during a call or a context switch does not add to its figure.
- Context switch
- Saving the outgoing thread’s context and restoring the next.
- Interrupts masked
- The longest stretch the kernel keeps interrupts masked, and so its contribution to interrupt latency.
Measure on your target
The instrumentation is a build option of KideRT. The profiling chapter describes how to enable it and how to read the report.
Read the profiling chapterBuild with instrumentation
Build KideRT with its timing instrumentation enabled. The kernel then records the longest time each system call takes.
Run on the target
Run your application, or a test that exercises the calls, on the target. The measurement needs the core’s cycle counter, which every supported core has except Cortex-M0+ and Cortex-M23.
Read the report
Read the kernel’s report, one line per call with its longest cycle count, and record the conditions above next to it.
Evaluate KideRT on your target
Request an evaluation and measure KideRT on your own hardware.