vchandra wrote on Thursday, April 09, 2009:
Hi,
I want to measure freeRTOS real time performance using NEC V850 micro controller. I am planning to use this input in design phase. So i have few doubts and if it is possible to clarify it, it will be great help.
1) Which parameters must be taken care during my real time performance evaluation?
[I know only: interrupt latency, context switch time]
2) How to measure interrupt latency, context switch time?
Regards
Vchandra
edwards3 wrote on Thursday, April 09, 2009:
Interrupt latency is predominantly a feature of the hardware. Differences in context switch times are generally insignificant.
You can compare lots of things, but they all trade off against each other.
aturowski wrote on Friday, April 10, 2009:
1) Almost every of inter process communication features in FreeRTOS is based on queues - please look for example in semaphores implementation source etc. Measuring queues performance will give you a clue how to design the best solution. Also you have to remember that non-blocking version of calls (wait time parameter equals to zero) will not use scheduler, which make them running faster than the same call with wait time not equal to zero. Semaphores are just queues. Mutexes are slightly different, because they use priority inheritance. It makes them running slightly slower than semaphore.
To have a feel regarding RTOS latency timining you should make performance measurements for ISR versions of Receive and Send from/to queue.
2) To make accurate measurement you should use hardware timer or scope and PIO pin.
Please publish the results. Please be aware that they first should be sent to Richard (richardbarry) to review before publishing.
rtel wrote on Friday, April 10, 2009:
FreeRTOS V5.2.0 has some improvements to the queue performance.
Regards.
vchandra wrote on Friday, April 10, 2009:
Dear All
Thanks for your valuable inputs. I will share my views with following details in next post:
1. Benchmark parameters for real time performance measurement.
2. freeRTOS and uc performance measurement methods
So that you can validate and correct me.
Regards
Vchandra
vchandra wrote on Thursday, April 23, 2009:
Dear All
I have identified some parameters to measure/evaluate freeRTOS.
1. Interrupt latency time (considered even though it is based on uC architectural design)
2. Context switch time
3. Kernel CCR consumption
4. Kernel API performance
I have done measurement with NEC v850 architecture with 2MHz osc. frequency (too slow…still i must to re-use my existing lab setup).
I would like share my measurement methods for latency and context switch time. So that you proivde your valuable feedbacks…
INTERRUPT LATENCY TIME:
Intention of this measurement is to identify minimal interrupt latency time.
Test code
1. Configure two IO pins (TestPin1, TestPin2) as described below:
a) TestPin1 as output mode.
b) TestPin2 as external interrupt port with falling edge detection option. So default state is HIGH.
2. Create a task which sets TestPin1 as always LOW.
3. Create an external interrupt ISR, set TestPin1 as HIGH.
Measurement method
1. Connect TestPin1, TestPin2 ports to DSO channel 2, channel 1 respectively.
2. Give falling edge trigger to TestPin2 port.
3. Measure time difference between interrupt generated time (HIGH to LOW transition at TestPin2) and time at which start executing the first instruction in the ISR (LOW to HIGH transition at TestPin1).
CONTEXT SWITCH TIME :
Context switch can be triggered by different sources like external interrupt, kernel services, timer interrupt etc., So, different methods are available to measure context switch time. For evaluation purpose, two methods are identified and average of those measurements is considered as context switch time.
Method_1: tick ISR to TASK switch
Test code
1. Configure one IO pin (TestPin1) as output mode.
2. Configure a hardware timer as 8ms interval timer, which is used as system tick.
3. Add the following code in “8ms interval timer” ISR function:
a) Set TestPin1 as HIGH at the start of ISR function.
Rationale: “freeRTOS” kernel designed in such a way that scheduler function (it ensures that which task to run next) is called from tick ISR routine. So, this tick is executed every 8ms and it switched back to always with high priority task. So, task switch time is time taken to execute scheduler function and also switching time from tick ISR to high priority task.
4. Create one task which makes TestPin1 as always LOW.
Measurement method
1. Connect TestPin1 port to DSO channel 1.
2. Measure CRO channel 1 out waveform. Calculate context switching time using below formula:
Context switch time = tab - X
tab - Time taken to execute complete tick ISR function and also switching back to high priority task.
X - Time taken to execute tick increment function. So this must be measured separately using test pin toggling method with tick increment function.
Method_2: TASK to TASK switch using a Kernel services (vTaskSuspend ( ), vTaskResume ( ))
Test code
1. Configure one IO pin (TestPin1) as output mode.
2. Create two tasks as described below:
a) Task1: “HighPrioTask” with priority 4.
b) Task2: “LowPrioTask” with priority 3.
3. Add the following code in “HighPrioTask”:
a) Suspend “HighPrioTask” task.
b) Set TestPin1 as HIGH
4. Add the following code in “LowPrioTask”:
a) Give 2 ms delay.
b) Set TestPin1 as LOW and then HIGH (Toggle it once)
c) Set TestPin1 as LOW
d) Resume “HighPrioTask” task.
Measurement method
1. Connect TestPin1 port to DSO channel 0.
2. Measure CRO channel 0 out waveform.
Time taken from step 4.c to step 3.b is called as context switch time.
I am unable provide waveform diagrams. I dont know how much helpful to understand my views. Still…
aturowski wrote on Thursday, April 23, 2009:
Looks quite good. Remember that the avereage time as well as max time are the most interesting parameters for developers. To measure max time you can use infinite persistence capability in DSO.