时钟节拍是特定的周期性中断。这个中断可以看作是系统心脏的脉动。中断之间的时间间隔取决于不同的应用，一般在10mS到200mS之间。时钟的节拍式中断使得内核可以将任务延时若干个整数时钟节拍，以及当任务等待事件发生时，提供等待超时的依据。时钟节拍率越快，系统的额外开销就越大。

    各种实时内核都有将任务延时若干个时钟节拍的功能。然而这并不意味着延时的精度是1个时钟节拍，只是在每个时钟节拍中断到来时对任务延时做一次裁决而已。

    图2.25到 图2.27示意任务将自身延迟一个时钟节拍的时序。阴影部分是各部分程序的执行时间。请注意，相应的程序运行时间是长短不一的，这反映了程序中含有循环和条件转移语句(即if/else, switch, ? : 等语句)的典型情况。时间节拍中断服务子程序的运行时间也是不一样的。尽管在图中画得有所夸大。

    第一种情况如图2.25所示，优先级高的任务和中断服务超前于要求延时一个时钟节拍的任务运行。可以看出，虽然该任务想要延时20mS，但由于其优先级的缘故，实际上每次延时多少是变化的，这就引起了任务执行时间的抖动。

    第二种情况，如图2.26所示，所有高优先级的任务和中断服务的执行时间略微小于一个时钟节拍。如果任务将自己延时一个时钟节拍的请求刚好发生在下一个时钟节拍之前，这个任务的再次执行几乎是立即开始的。因此，如果要求任务的延迟至少为一个时钟节拍的话，则要多定义一个延时时钟节拍。换句话说，如果想要将一个任务至少延迟5个时钟节拍的话，得在程序中延时6个时钟节拍。 

图2.25将任务延迟一个时钟节拍(第一种情况)

图2.26将任务延迟一个时钟节拍(第二种情况)

图2.27将任务延迟一个时钟节拍(第三种情况)

第三种情况，如图2.27所示，所有高优先级的任务加上中断服务的执行时间长于一个时钟节拍。在这种情况下，拟延迟一个时钟节拍的任务实际上在两个时钟节拍后开始运行，引起了延迟时间超差。这在某些应用中或许是可以的，而在多数情况下是不可接受的。

上述情况在所有的实时内核中都会出现，这与CPU负荷有关，也可能与系统设计不正确有关。以下是这类问题可能的解决方案： 

l 增加微处理器的时钟频率

l 增加时钟节拍的频率

l 重新安排任务的优先级

l 避免使用浮点运算(如果非使用不可，尽量用单精度数)

l 使用能较好地优化程序代码的编译器

l 时间要求苛刻的代码用汇编语言写

l 如果可能，用同一家族的更快的微处理器做系统升级。如从8086向80186升级，从68000向68020升级等

l 不管怎么样，抖动总是存在的。