rtel wrote on Thursday, September 25, 2008:
> Are there any FreeRtos projects setup specifically to measure
> real-time performance, or perhaps suggestions of how best to
> go about this type of testing?
You might like to look at the LM3Sxxx demos to start with. These have standard tasks running at various priorities (including a WEB server), with medium frequency interrupts that nest with each other (and the kernel) fight to access a common resources (queues), and finally a high frequency (20KHz) running at a high priority. The LCD then displays the jitter measured in the high frequency interrupt. The CPU is heavily loaded.
Measuring real time performance is very difficult unless you have a clear definition of exactly what you are interested in. I always tell people to believe nothing that is written and take the measurements themselves. You only have to look at the claims and counter claims about the quality of the GCC compiler compared to commercial compilers (most of which are complete nonsense when you actually look into the test environments), or the speed of one processor when compared to another.
I’m getting a bit off topic and philosophical maybe but…improving the ‘performance’ of FreeRTOS as measured by how quickly a semaphore can be given, or data to be passed to a queue, etc. would be very easy. All I would have to do is remove the scheduler locking and responsiveness tuned execution flow and just stick the entire function definition in one big critical section. While this would make the functions super quick, I’m sure you would agree it would not make a better system as responsiveness would nose dive. Engineering is always about finding the best compromise given the resources (CPU power, RAM, etc.) available.
> I am looking for a way that I can reasonably claim that the
> overall system and components (OS) are time deterministic to
> some degree. This may mean that all scheduled tasks begin
> execution within x msec of their ideal start time,
This is going to be very application dependent - FreeRTOS.org is not a time/space separated kernel, like Green Hills Integrity for example. You can assign your task priorities with consideration of ideal start times, with the help of various analysis techniques, etc,. It is still going to depend on your application design more than the RTOS.
> or it may
> mean that the relationship between loading and latency is
> characterized.
> This type of proof could be data collected from tracing or
> scope measurements (or even simulation), but I’d also be
> interested in seeing any claims about the OS components, “all
> APIs execute O(log n) or better” type of claims.
The trace macros are provided for taking timings, etc.
> Since measured performance is application dependant,
I should have read down this far first ;o)
> I am
> thinking two categories of tests. One would focus on
> measuring the timeliness of the scheduler and other OS APIs,
> and might have a set of dummy tasks with adjustable loading
> to see how loading affects determinism.
>
> The second type of test would focus on the application, and
> help identify problem areas.
Can I ask what you are requiring this data for? I might be able to suggest something appropriate.
Regards.