Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Possible scheduler unfairness?

Posted by Friedrich Lobenstock on April 10, 2013
Hi!

I've got a port up and running a demo with the
following tasks and their priorities:

--------------------
Task Name Priority
--------------------
Tmr Svc 4
BTest1 2
QConsB1 2
QProdB4 2
BTest2 1
IntMath 0
QConsB3 0
QConsB6 0
QProdB2 0
QProdB5 0
Reg1 0
Reg2 0
IDLE 0
Stats 0
--------------------


I've implemented a statistics task that prints the
statistics gathered every 60 seconds on the serial
console. The system tick is running at an interval
of 1ms, and the stats timer at 100us.

After letting the system run for some time we get the
following result:

-------------- RUN TIME STATISTICS ---------------
--------------------------------------------------
Task Name 1/10 Ticks Percentage
--------------------------------------------------
IDLE 24828 <1%
IntMath 27909887 33%
QProdB2 88840 <1%
QConsB3 94174 <1%
QProdB5 1431541 1%
QConsB6 1447645 1%
Reg1 19473930 23%
Stats 8326 <1%
Reg2 27934058 33%
BTest2 64616 <1%
QConsB1 2738151 3%
QProdB4 2724660 3%
Tmr Svc 2801 <1%
BTest1 56573 <1%
--------------------------------------------------
TOTAL TICKS 8400000
STATS EXE TICKS 7
PRINT EXE TICKS 2301
--------------------------------------------------


After intuitively replacing "<1%" with 0,5%, we get
the following result:

--------------------------------------------------
Task Name 1/10 Ticks Percentage Priority
--------------------------------------------------
IntMath 27909887 33,00% 0
Reg2 27934058 33,00% 0
Reg1 19473930 23,00% 0
QConsB1 2738151 3,00% 2
QProdB4 2724660 3,00% 2
QConsB6 1447645 1,00% 0
QProdB5 1431541 1,00% 0
BTest1 56573 0,50% 2
BTest2 64616 0,50% 1
IDLE 24828 0,50% 0
QConsB3 94174 0,50% 0
QProdB2 88840 0,50% 0
Stats 8326 0,50% 0
Tmr Svc 2801 0,50% 4
--------------------------------------------------
SUM 84000030 100,50%
--------------------------------------------------


The time divided by 10 pretty much adds up to 8400000
and the percentage almost adds up to 100% as well.

BUT it seems all other tasks are only stealing time
from task "Reg1". The tasks "Reg2" and "IntMath" seem
to get their fair share of the CPU.

Is this a result of an unfairness of the scheduler or
where is this result possibly coming from?

Can someone possibly shed some light on this?

Regards
Friedl

RE: Possible scheduler unfairness?

Posted by Richard on April 10, 2013
Some tasks use their entire time slice, other tasks do something very briefly then yield (be it explicitly by calling taskYIELD() or by blocking on a queue or semaphore, or even by posting to a queue or semaphore that unblocks a higher priority task resulting in preemption).

In this artificial demo task environment, tasks that execute after a task that only used part of a time slice will only ever get part of a time slice themselves. If they start half way through a time slice then they will get swapped out again at the end of the time slice. Real applications do not normally result in this type of execution pattern because real tasks are performing real functionality.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS