Period, execution time and jitter
A task configured for 5 ms does not necessarily start at exactly every 5 ms timestamp.
Activation versus execution
Activation makes a task eligible according to the OS rules. Scheduling determines when it actually runs. Higher-priority work, interrupts, resource locks and core load can delay execution. Measure activation and start separately.
Name the timing metric
Execution time measures CPU time consumed under a stated definition. Response time measures from an event or activation to completion. Jitter describes variation in a chosen timing quantity. Always state the reference points rather than reporting a single ambiguous timing number.
Move work with evidence
Moving work to another core can reduce interference but introduces communication and synchronization costs. Compare before-and-after traces under the same stimulus and load. Check deadlines and data consistency as well as average timing.
Follow each transition
Activation
The configured event makes work eligible.
Conceptual sequence. Timing is slowed for learning; it is not a hardware measurement.
Your investigation
A 5 ms task sometimes starts 1 ms late but runs for 0.2 ms. Is the cause necessarily slow task code?
Reveal the investigation checklist
- Capture activation, start and finish timestamps.
- Inspect ISR and higher-priority execution.
- Inspect resource blocking.
- Evaluate response-time bounds under worst relevant load.
Which interval includes waiting before a task runs?
Answer the knowledge check correctly to complete this lesson.
Think through Period, execution time and jitter
Ask for an explanation, an automotive example or a question that tests your understanding.
Checking mentor availability…