关于实时操作系统的性能指标的判定与分析

关于实时操作系统的性能指标的判定与分析

前言

在嵌入式软件设计和集成中，实时多任务操作系统的性能分析是至关重要的，它需要保证应用的时间限制得到满足，即是运行时间不能超过应用的时间限制。为了选择满足用于特定应用的嵌入式系统的一个适当的操作系统,我们需要对操作系统服务进行分析。这些操作系统服务是由形成性能指标的参数确定的，既定的性能指标包括上下文开关时间、抢占时间、中断延迟、信号洗牌时间。

关于实时操作系统对性能指标进行分析，是为了选择满足用于特定应用的嵌入式系统的最优的操作系统。

什么是嵌入式系统

一个嵌入式系统是由硬件、软件和其他为了执行具体功能而设计的机械部件所组成，嵌入式系统通常包含除了特定的应用硬件之外还有可编程处理器和外围设备。底层应用硬件的复杂性，紧张的性能和功率预算，以及开发进度要求应用程序开发人员使用执行时期支持软件。这种支持通常采用实时操作系统，运行库和设备驱动程序的形式。 RTOS被应用于包含软实时限制的嵌入式系统中，以及包含硬实时限制的正式实时系统。

RTOS向嵌入式系统设计师提供了一系列服务，如利用任务管理，内存管理，以及资源管理来构建一个应用程序。

为嵌入式系统选择最优的OS是基于系统设计师可用的OS以及他们前期的知识积累和经验。这可能导致OS与嵌入式系统的不匹配。

嵌入式系统的一个主要的子类就是实时嵌入式系统。实时系统即是有时间限制的系统。实时系统的性能依据是能否及时运算并做出决策的能力。这些运算具有完成截止时间要求，错过了截止时间和得出错误结果是一样糟糕的。由这个错误造成的损失程度取决于应用程序。例如，如果这个实时系统是飞机飞行控制系统的一部分，仅错过截止时间就足以危及乘客和工作人员的生命安全。

什么是实时操作系统

定义：一个实时操作系统是一个程序，它按照时序的方式调度执行任务，并管理系统资源，为开发应用程序代码提供一致的基础。

操作系统并不是任何一个计算机系统必须的组成部分。一个简单的微波炉并不需要操作系统，但是，随着应用的复杂性逐步扩展，操作系统的好处远远大于其成本。

由于嵌入式系统（PDA，手机，录像机，工业机器人控制，甚至是烤面包机）正变得越来越复杂，为了满足系统响应要求，并保证合理的开发时间，我们需要设计合理的操作系统。

RTOS的使用能够通过任务分解进一步简化设计，通过抢占式处理，保证关键任务能够及时有效地得到处理。RTOS允许通过提供诸如信号量，邮箱机制，队列，时间延迟，时间戳等服务来更好的利用系统资源。

Figure 1：RTOS常见组成

基准测试 （Benchmark Test, 即BMT）

基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。例如，对计算机CPU进行浮点运算、数据访问的带宽和延迟等指标的基准测试，可以使用户清楚地了解每一款CPU的运算性能及作业吞吐能力是否满足应用程序的要求。

从上述例子我们可以看出，可测量、可重复、可对比是基准测试的三大原则，其中可测量是指测试的输入和输出之间是可达的，也就是测试过程是可以实现的，并且测试的结果可以量化表现；可重复是指按照测试过程实现的结果是相同的或处于可接受的置信区间之内，而不受测试的时间、地点和执行者的影响；可对比是指一类测试对象的测试结果具有线性关系，测试结果的大小直接决定性能的高低。

　　在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。

　　基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。当软件系统中增加了1个新模块，此时需要做基准测试，以判断新的模块对整个软件系统的性能影响。

A． 基准的分类

1. 复合基准测试

复合基准测试用于测量系统、处理器、编译器的多方面特性。复合基准试图模拟出真实世界中的应用的指令混合。它主要用于调试特定功能，但是它们并不涉及应用软件中的功能如何实现。所以它不是必须的基准测试。

2. 应用基准测试

应用基准也被称为“真实世界”基准点，它使用系统软件或者用户层软件代码形成真正的算法。应用基准在系统层基准测试中更常用，通常具有大量的代码和数据存储需求。

3. 派生基准测试

派生基准也称为“基于算法的基准点”，它是前两种基准点的折中。顾名思义，派生基准是通过提起关键算法，从实际应用中生成真实数据集，这避免了 执行整个应用程序的需要，派生基准可以用于调试、内部构造，以及对比分析。派生基准基于实际应用，尤其适用于嵌入式环境。

B． 实时系统的性能基准

“基准“系列适用于某些实时操作系统。他们的目标是不同的，当其他人关注嵌入式微控制器I/ O处理时，有些人在试图测量台式电脑的浮点性能。一些可用的基准似乎符合小处理器（如摩托罗拉处理器），并能够满足实时环境的需求。系统实时性的测量基准有：

1. Whetstone

它是综合性测试程序，主要包括浮点运算、整数算术运算、功能调用、数组变址、条件转移、超越函数。测试结果用单位Kwips表示，1Kwips表示机器每秒钟能执行1000条Whetstone指令。Whetstone基准可用于嵌入式系统和编译器的比较。

2. Dhrystone

它是测量处理器运算能力的最常见基准程序之一，常用于测量指令集执行时间。该指令集被认为是高级语言中调用函数集的典型代表。指令之间的分布是：53％用于分配，32％用于控制，15％用于程序和函数调用。但是Dhrystone的重心是并不常用于嵌入式系统中的字符串任务。

3. Hartstone

Hartstone性能基准程序是用Ada语言编写，是依据硬实时测试需求构成的一组合成应用。Hartstone性能基准程序需要不同测试序列，每个测试序列中的测试结果只有2种情况：满足或者不满足时间限制。若任一个程序不满足时限，那么测试结论就是“不通过”。共有5种测试序列：

1. 任务周期有规律的周期性任务；

2. 任务周期无规律的周期性任务；

3. 任务周期有规律但非周期性处理的周期性任务；

4. 任务周期有规律有同步的周期性任务；

5. 任务周期有规律有同步但非周期性处理的周期性任务。

4. Rhealstone

Rhealstone性能基准程序是 实时系统的六个关键操作的时间量进行操作，这六个关键操作是：上下文切换时间、抢占时间、中断延迟、信号量洗牌时间、死锁解除时间、信息传递延迟。这六项操作作为Rhealstone的六个组件，每个组件被单独测量。然后将经验结果合并为单一的测量值，即是Rhealstone值。这里有两种方式测量Rhealstone值：一是通用Rhealstone；二是每个组件应用于具体应用程序的特定Rhealstone。

Rhealstone性能基准程序有2个缺点，一是它测量的是平均时间，而不是最坏值；二是其最后的结论是加权平均值，没有给出确定权值的依据。

关键的性能指标分析

一个实时操作系统的实时性能的主要评测指标包括上下文切换时间，抢占时间，中断延迟时间，信号量混洗时间。具体含义如下：

1. 上下文交换时间

上下文切换时间也称任务切换时间(task switching time)，定义为系统在两个独立的、处于就绪态并且具有相同优先级的任务之间切换所需要的时间。它包括三个部分，即保存当前任务上下文的时间、调度程序选中新任务的时间和恢复新任务上下文的时间。切换所需的时间主要取决于保存任务上下文所用的数据结构以及操作系统采用的调度算法的效率。产生任务切换的原因可以是资源可得，信号量的获取等。任务切换是任一多任务系统中基本效率的测量点，它是同步的，非抢占的，实时控制软件实现了一种基于同等优先级任务的时间片轮转算法。影响任务切换的因素有：主机CPU的结构，指令集以及CPU特性。

任务切换过程增加了应用程序的额外负荷。CPU的内部寄存器越多，额外负荷就越重。任务切换所需要的时间取决于CPU有多少寄存器要入栈。实时内核的性能不应该以每秒钟能做多少次任务切换来评价，RTOS中通常是1微秒左右。

Figure 2: Context Switch Time

T1 = TIME START FOR FUNCTION “OS_TASK_SW()”(任务切换宏)

T2 = TIME END FOR FUNCTION “OS_TASK_SW()”

CST= T2-T1

2. 抢占时间（preemption time）

抢占时间即系统将控制权从低优先级的任务转移到高优先级任务所花费的时间。为了对任务进行抢占，系统必须首先识别引起高优先级任务就绪的事件，比较两个任务的优先级，最后进行任务的切换，所以抢占时间中包括了任务切换时间。

它和任务切换有些类似，但是抢占时间通常花费时间更长。这是因为执行中首先要确认唤醒事件，并评估正在运行的任务和请求运行的任务的优先级高低，然后才决定是否切换任务。实质上，所有的多处理任务可以在执行期间动态分配优先级，所以，抢占时间也是衡量实时性能的重要指标。

Figure 3: Preemption Time

PT = T2 – T0

3. 中断延迟(Interrupt Latency)

中断延迟时间是指从接收到中断信号到操作系统做出响应，并完成进入中断服务例程所需要的时间。多任务操作系统中，中断处理首先进入一个中断服务的总控程序，然后才进入驱动程序的ISR。

中断延迟时间＝最大关中断时间＋硬件开始处理中断到开始执行中断服务例程第一条指令之间的时间。

硬件开始处理中断到开始执行中断服务例程的第一条指令之间的时间由硬件决定，所以，中断延迟时间的长短主要取决于最大关中断的时间。硬实时操作系统的关中断时间通常是几微秒，而Linux最坏可达几毫秒。

Figure 4: Interrupt Latency

IL= Max(Ta,Tb,Tc)

4. 信号量混洗时间

信号量混洗时间(semaphore shuffling time)，是指从一个任务释放信号量到另一个等待该信号量的任务被激活的时间延迟。在RTOS中，通常有许多任务同时竞争某一共享资源，基于信号量的互斥访问保证了任一时刻只有一个任务能够访问公共资源。信号量混洗时间反映了与互斥有关的时间开销，因此也是衡量ERTOS实时性能的一个重要指标。

Figure 5: Semaphore Shuffling Time

SST = T0-T1

OSSemPend和OSSemPost

typedefstruct{

INT8UOSEventType;/*Typeofeventcontrolblock(seeOS_EVENT_TYPE_???)*/ INT8UOSEventGrp;/*Groupcorrespondingtotaskswaitingforeventtooccur*/

INT16UOSEventCnt;/*SemaphoreCount(notusedifotherEVENTtype)*/

void*OSEventPtr;/*Pointertomessageorqueuestructure*/

INT8UOSEventTbl[OS_EVENT_TBL_SIZE];/*Listoftaskswaitingforeventtooccur*/ }OS_EVENT;

主要看的是OSEventCnt，这个是资源数目，创建的时候使用OSSemCreate(INT16Ucnt)把cnt传递给它。

当需要使用这个资源的时候，需要先调用OSSemPend(OS_EVENT*pevent,INT16Utimeout,INT8U*err)

如果资源数目大于0，申请资源成功，资源数目减1，然后返回

如果资源数目等于0，则要等待，timeout定义了超时时间，如果等待的周期数小于timeout，则返回继续执行，否则err=OS_TIMEOUT

在检测到资源数目等于0进行等待的时候会进行任务切换OS_Sched();

还有一个函数是OSSemPost(OS_EVENT*pevent)，这个函数是释放资源，执行后资源数目会加1 ；在使用某个信号量之前需要创建它，创建时候唯一的参数就是资源的数目，如果是一块缓冲区，这个数目应该是缓冲区的大小，如果是比如串口资源，则资源数目应该待于1所以在调用OSSemPend（）时，一定要检测它的返回类型，即err，如果不检测它的话，没有什么意义，这有几种类型，分别是：

OS_ERR_PEND_ISROS_ERR_PEVENT_NULL：没有创建该信号量

OS_ERR_EVENT_TYPE：OSEventType类型不匹配

OS_NO_ERR:成功

OS_TIMEOUT:超时

数据分析

In Table 1, column 1 has the performance parameters for which the Metrics number needs to be generated; column 2 has the time “T” required for each performance parameter in microsecond. “T” is the measurement of time duration between time initialization and termination for each performance parameter. Column 3 has the number of times that performance parameter is called denoted by “W”. “W” is the weight assigned to the each performance parameter for that specific application. Column 4 has the weighted value of each performance parameter. Column 5 has the summation of all weighted measurements. The inverse of sum of weighted measurements gives us a Metrics Number. Greater the Metrics number better is the operating system for that specific application。