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?
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.
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?"
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
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
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.
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.
"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...
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.