FreeRTOS updated

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
V1.2.1 of FreeRTOS is now available on http://www.FreeRTOS.org .  This
contains a minor update which improves the context switch time by
approximately 10%.




Re: FreeRTOS updated

Quoted text here. Click to load it

This is not a critical comment, but does this really make a difference.

In my last job we had a few timing problems and everyone was blaming
the context switch, so I crafted a test to time it.  Turned out the total
switching time was a fraction of one percent of the total run time of the
ap. Saving 10% of nothing isn't going to help much

Tim


Quoted text here. Click to load it


Re: FreeRTOS updated

Quoted text here. Click to load it

Well that all depends on your quantum time.....

Ralph



Re: FreeRTOS updated
On Mon, 18 Aug 2003 18:36:43 +0200, "tim"

Quoted text here. Click to load it

Working for the last 4 years writing/designing RTOSes, I can only copy
this, __but__ that's what we first hear as question:
How fast is the context switch ?
More interessting IMHO is the IPC. Or the interrupts turn around
times.
(And this maybe compared to the task-switch times).
E.g. using a classical *nix mailbox (AFAIK FreeRTOS uses this
technique as well) sending a 100 bytes means to copy 200 bytes (into
and out of the mailbox). On a x86 the context (aka register set) to be
saved are about 14 registers, means 56bytes + restore 56bytes are 112
bytes => the IPC takes more time than the context switch.
(Neglecting that of course the IPC is not only copying !)

So, when optimizing the whole IPC path must be quick => See L4.
---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: FreeRTOS updated

Quoted text here. Click to load it

Sure, and I could create tasks that could actually show a degradation of
overall performance from an increase in processor speed.

You probably should have said:

     Saving 10% of nothing isn't going to help ME much.

How many context switches do you do?  Other system designs might
get a full 10% improvement (or more) due to the changes, if the tasks
execution times are very short (for example, state machine evaluations).

If optimal polling time was at say, 95% of the old context switch and task
execution time, this change could yield near 100% improvement.

I just think you can't generalize the value of an improvement based on
one personal observation.

Rufus








Re: FreeRTOS updated
Can anyone suggest resources (links, books) to better understand the theory,
design and issues behind RTOS's?

Thanks,

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

We've slightly trimmed the long signature. Click to see the full one.
Re: FreeRTOS updated
I have written a reference document to our real-time operating system.

It explains what an operating system is (for embedded systems, not in the
general case) and the inner working of a kernel.

You can download this document at our web site:
http://www.EmbeddedArtists.com -> Select: Download

In fact, you can also download our configurable real-time operating system
(also under 'download' - you will have to install our graphical
configuration tool first). Our RTOS is free for non-commercial use, and it
is portable to virtually any processor.

By studying the source code, you will typically learn the inner working of a
real-time operating system.

I have also compiled a list of recommended books, and there is a section
covering real-time operating systems. This list can also be found  under the
'Knowledge' menu at our web site.



Best of luck!

Anders Rosvall

Embedded Artists




Quoted text here. Click to load it
theory,
This
difference.
task



Re: FreeRTOS updated
I'll look that over, thank you.

-Martin



Quoted text here. Click to load it
a
the
of
of
evaluations).
Quoted text here. Click to load it



Re: FreeRTOS updated

Quoted text here. Click to load it

You seem to have extrapolated from what I said to the reason being
that we didn't switch task very often.  The point is the switching time is
small overall (or should be) so making it smaller doesn't save very much
IMHO.

Quoted text here. Click to load it

You going to have a huge OS overhead if you save this much.  A better
design might be a more appropriate way of saving time.

Quoted text here. Click to load it

Actually it was,  but the guts of the work was handled in interrupts and
didn't go through the OS context change.

Quoted text here. Click to load it

How is this going to work?  Oh, currently the OS uses 95% of
the time and now it uses 90%.  Sorry, you've got a crap OS if this
is your profile.

Quoted text here. Click to load it

I think I can.  If your OS is so busy that a small change in the function
that saves context when task switching is significant, where is all the
time coming from to perform all the other functionality?

Tim


Quoted text here. Click to load it


Re: FreeRTOS updated

Quoted text here. Click to load it


To some it will.  Or, to maybe coin a phrase:  

    There is no such thing as "fast enough for everyone".

The net effect that 10% speed-up can be both invisibly small, or make
the difference between a working product and failure, depending on the
particular project.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Site Timeline