时钟节拍(Clock Tick)
时钟节拍是特定的周期性中断。这个中断可以看作是系统心脏的脉动。时钟的节拍式中断使得内核可以将任务延时若干个整数时钟节拍，以及当任务等待事件发生时，提供等待超时的依据。时钟节拍率越快，系统的额外开销就越大。
各种实时内核都有将任务延时若干个时钟节拍的功能。然而这并不意味着延时的精度是1个时钟节拍，只是在每个时钟节拍中断到来时对任务延时做一次裁决而已。
第一种情况如图一所示，优先级高的任务和中断服务超前于要求延时一个时钟节拍的任务运行。可以看出，虽然该任务想要延时20mS，但由于其优先级的缘故，实际上每次延时多少是变化的，这就引起了任务执行时间的抖动。
第二种情况，如图8.2所示，所有高优先级的任务和中断服务的执行时间略微小于一个时钟节拍。如果任务将自己延时一个时钟节拍的请求刚好发生在下一个时钟节拍之前，这个任务的再次执行几乎是立即开始的。因此，如果要求任务的延迟至少为一个时钟节拍的话，则要多定义一个延时时钟节拍。换句话说，如果想要将一个任务至少延迟5个时钟节拍的话，得在程序中延时6个时钟节拍。
图8.1将任务延迟一个时钟节拍(第一种情况)
图8.2将任务延迟一个时钟节拍(第二种情况)
图8.3将任务延迟一个时钟节拍(第三种情况)
第三种情况，如图8.3所示，所有高优先级的任务加上中断服务的执行时间长于一个时钟节拍。在这种情况下，拟延迟一个时钟节拍的任务实际上在两个时钟节拍后开始运行，引起了延迟时间超差。这在某些应用中或许是可以的，而在多数情况下是不可接受的。
上述情况在所有的实时内核中都会出现，这与CPU负荷有关，也可能与系统设计不正确有关。以下是这类问题可能的解决方案：
- l 增加微处理器的时钟频率
- l 增加时钟节拍的频率
- l 重新安排任务的优先级
- l 避免使用浮点运算(如果非使用不可，尽量用单精度数)
- l 使用能较好地优化程序代码的编译器
- l 时间要求苛刻的代码用汇编语言写
- l 如果可能，用同一家族的更快的微处理器做系统升级。如从8086向80186升级，从68000向68020升级等
对存储器的需求
如果设计是前后台系统，对存储器容量的需求仅仅取决于应用程序代码。而使用多任务内核时的情况则很不一样。内核本身需要额外的代码空间(ROM)。内核的大小取决于多种因素，取决于内核的特性，从1K到100K字节都是可能的。8位CPU用的最小内核只提供任务调度、任务切换、信号量处理、延时及超时服务约需要1K到3K代码空间。代码空间总需求量由:
总代码量= 应用程序代码+ 内核代码
因为每个任务都是独立运行的，必须给每个任务提供单独的栈空间(RAM)。应用程序设计人员决定分配给每个任务多少栈空间时，应该尽可能使之接近实际需求量(有时，这是相当困难的一件事)。栈空间的大小不仅仅要计算任务本身的需求(局部变量、函数调用等等)，还需要计算最多中断嵌套层数(保存寄存器、中断服务程序中的局部变量等)。根据不同的目标微处理器和内核的类型，任务栈和系统栈可以是分开的。系统栈专门用于处理中断级代码。这样做有许多好处，每个任务需要的栈空间可以大大减少。所有内核都需要额外的栈空间以保证内部变量、数据结构、队列等。如果内核不支持单独的中断用栈，总的RAM需求:
RAM总需求= 应用程序的RAM需求+ (任务栈需求+ 最大中断嵌套栈需求) * 任务数
如果内核支持中断用栈分离，总RAM需求量:
RAM总需求= 应用程序的RAM需求+ 内核数据区的RAM需求+ 各任务栈需求之总和+ 最多中断嵌套之栈需求
除非有特别大的RAM空间可以所用，对栈空间的分配与使用要非常小心。为减少应用程序需要的RAM空间，对每个任务栈空间的使用都要非常小心，特别要注意以下几点：
l 定义函数和中断服务子程序中的局部变量，特别是定义大型数组和数据结构
l 函数(即子程序)的嵌套
l 中断嵌套
l 库函数需要的栈空间
l 多变元的函数调用
综上所述，多任务系统比前后台系统需要更多的代码空间(ROM)和数据空间(RAM)。额外的代码空间取决于内核的大小，而RAM的用量取决于系统中的任务数。
使用实时内核的优缺点
实时内核也称为实时操作系统或RTOS。使用可剥夺性内核时，所有时间要求苛刻的事件都得到了尽可能快捷、有效的处理。通过有效的服务，如信号量、邮箱、队列、延时、超时等，RTOS使得资源得到更好的利用。
一些软件包是完整的操作系统，不仅包括实时内核，还包括输入输出管理、视窗系统(用于显示)、文件系统、网络、语言接口库、调试软件、交叉平台编译(Cross-Platform compilers)。