Posing an alternative to "best practice" for jitter

Michael Barr wrote about jitter in a recent blog posting at Embedded Gurus. Here's what Michael had to say and our alternative suggestion.

"Best Practice: The most important single factor in the amount of jitter is the relative priority of the task or ISR that implements the recurrent behavior. The higher the priority the lower the jitter. The periodic reads of those encoder pulse counts should thus typically be in a timer tick ISR rather than in an RTOS task."

We believe jitter (the difference between longest time and shortest time) needs to be controlled for the inputs and the outputs for time-sensitive applications. This suggests an alternative to Barr’s best practice:

• Split the jitter-sensitive parts (i.e. I/O operations) from the computational parts.
• Write the I/O operations to minimize jitter. This can be done by focusing optimization on the worst case. Optimizing the worst case has the effect of reducing the difference between the maximum and minimum execution times, unlike optimizing for average case, which can have the opposite effect.
• Put the I/O operations in a high priority thread/interrupt.
• Data processing (converting inputs to outputs) can be done as a lower priority activity.

If the I/O task is triggered by a timer interrupt, the gap between interrupts gives a deadline on the lower priority execution. This should be checked for schedulability, but other than that, the completion time of the lower priority task can be variable without affecting the input and output jitter. Andrew