Any RTOS to report latencies?

Greetings,

I am wondering are there RTOSes that document interrupt and task switching latencies on supported platforms and provide with tools to validate that. I read some advertising hype from OS vendors on how small their latencies are, but there were no numbers. There were also several independent studies that got to numbers, which OS salesmen probably prayed would have never been published :-)

So does anybody knows RTOS(es) that do document and validate the latencies on supported platforms?

D
Reply to
Stargazer
Loading thread data ...

I know that VxWorks has a testsuite that does measure a lot of things including task switches, etc. You can ask for the results for certain boards/processors, but you can also request the test suite to run it on your own hardware.

Kind regards, Johan Borkhuis

Reply to
borkhuis

RTA-OSEK from ETAS does. The "Binding Manual" provides full details of all latencies and WCETs in the OS - these are validated on a reference board, and the intention was that the Timing Characterisation Library that enabled these latencies to be measured should be available to customers to determine these figures on their own hardware.

Disclaimer - I used to work there...

pete

--
pete@fenelon.com "how many clever men have called the sun a fool?"
Reply to
Pete Fenelon

As does eCos.

--
Grant Edwards                   grante             Yow! If I felt any more
                                  at               SOPHISTICATED I would DIE
 Click to see the full signature
Reply to
Grant Edwards

I tend to be deeply suspicious of any self-reported OS timing measures, particularly latencies. Generally if I really need to know I instrument the code to toggle a pin when the task starts, then I look at the interrupt source (if it's external) on an oscilloscope and compare it to the task start. If I'm being really thorough I'll instrument the ISR, also. This gives me a trace that goes: _______________________________________ ___|

____|____________|_________________________

Note that if you have something that's _really_ time critical, and if you're blessed by it being simple, then you want to do it in the ISR, or even design it into hardware. Also, should latency be important, you need to be strict about protecting chunks of code -- the execution time of any block of code that's protected from interrupts adds directly to the interrupt latency.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

Those numbers are VERY dependent on the particular hardware/software, the mode of operation, the number of tasks and critical sections, wait states, DMAs, buses/caches/SDRAMs, etc. It is simple enough to figure out the latencies for the best case, however it is difficult if not impossible to account for the worst case.

You have to check it for yourself anyway, by toggling LEDs and tracing with a scope.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Don't believe anything you read - measure it yourself. Be very careful as to exactly WHAT any measurements are actually measuring, and that the OS state is consistent across all your tests.

I receive questionnaires occasionally from researchers, magazines, etc with reference to FreeRTOS.org. My favourite question is "What is the context switch time?". Last time I got this I wrote back and said, "what exactly to you want me to measure?" The answer came back "The time to switch from one task to another". I could not resist "On a PIC18 or a Pentium?" - to which they replied "whatever the average is". Enough said.

Another of my favourite quotes from an advert "20% faster context switch time", with no reference to what. LOL. Another, "fastest boot time, only x micro seconds" - without saying what is performed during the boot. Its all bull.

BTW, FreeRTOS.org does publish some numbers, but these are rather out of date. SafeRTOS has timing figures for nearly all operations (it has to for safety critical use), but this is only available in the purchased documentation or under NDA.

--
Regards,
Richard.
 Click to see the full signature
Reply to
FreeRTOS.org

ThreadX, from Express Logic, also provides this information. They offer hard numbers on specific processors that they have tested with. There are also a number of compilers that support "OS Awareness" for ThreadX which allow you to perform your own timing analysis on your specific processor. Just remember that these numbers are only valid if you follow the rules for your specific processor and / or operating system.

Reply to
husterk

I came across this recently

formatting link

Their Fido1100 seems to have a real-time focus, and they quote system jitter times, and MAX's, so you might get into there.

-jg

Reply to
Jim Granville

th

to

ne

ch

"Average" is good, LOL. While the time a task switch takes on a given system might be of interest, this is only minor anyway. What really matters is the IRQ latency (the OP _did_ ask about it which is pretty untypical, looks like he knows what he is after). This is again platform dependent, of course, but if I were to buy a system (which I am not, I am rather selling one) I would like to know whether the scheduler unmasks the IRQ while switching tasks, are there system calls which keep the IRQ masked for longer than others etc. On top of that there is code like device drivers etc. low level stuff which can also mask the interrupts, and while these may or may not be part of an OS just one of the wrong "model" could kill the latency figure beyond usability...

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

th

to

ne

ch

y x

ll

or

Reply to
Didi

Have you any ideas how good these devices are? They certainly sound interesting.

Reply to
David Brown

Mine too.

I once gave the numbers for a "imaginary" 1GHz ARM7 which impressed them :-))

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.