I just read that Linux with the RT patch can get latencies as low as 10uS, whilst a 'real' RTOS can get latencies down to 0.1uS.
For safety critical systems (i.e. ABS braking system) or factory automation (where the latency directly influences the throughput ) I'd probably opt for the lowest latency but there are plenty of systems where latencies can be higher.
Or is a lower latency always best?
The latency will also be dependent on the hardware on which you are running the system (how many clock cycles are needed to do a context switch and how fast the processor clock runs).
-- ******************************************************************** Paul E. Bennett............... Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Linux with RT patch is not available on as many platforms as real RTOS are, and is not flexible. So there is not much point in trying to make it work in a RT enviroment.
Latency is what every you need in an RTOS. Sometimes the latency is (relatively) low but you use one to manage power requirements anyway. I think FreeRTOS has an example of building a project 'superloop' compaired to RTOS, and it is commented once the multiple RT aspects are handled with RTOS you can then tune down or up the tick rate. ,
That statement is wrong, if only because it fails to name any hardware it's talking about.
What makes you assume that the limit on latency has anything to do with safety criticality?
No. Lower latency than you really need, at a higher price than you can afford, is never best.
Latency is dependent on the complete system, not just the OS, and is dependent on what is happening during different high-priority event handlers (i.e., if a high-priority interrupt handler takes a long time to run, it may have low latency but cause high latencies elsewhere).
And for some systems, average latency is more important than maximal latency (imagine a sampling system where there is a small external FIFO).
So for any safety-critical system where you want an analysis of the latencies, pick the simplest system you can. Linux, or any other large OS, would be a very bad choice for an ABS.
All else equal, lower latency is always best.
But all those other things are rarely ever equal.
If your OS is meeting the latency requirements for your application, then there isn't a lot of urgency in reducing it. There is an _advantage_, because it's always nice to have headroom for letting the latency grow as the product evolves, but if your application demands only a 1-second guaranteed latency and you're achieving 1/4 second, then you probably don't care much (and yes, that's an extreme example, but if you're controlling the level of water behind a dam it may be real, to, and life- critical to boot).
So whether you need a screaming fast real-time kernel that just provides task switching and otherwise stays the heck out of the way (which would probably be appropriate for those anti-lock brakes), or you need a full- featured OS to run some "big box" application that, incidentally, needs to put up picture-in-picture video without introducing more than a frame delay, pretty much determines whether you want something like freeRTOS or RT-Linux.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
It depends on the application.
I've done realtime control where the acceptable latencies for some areas were a full second.
Thank you Hans -- you said what I was trying to say, only much more succinctly (and with lower latency, too :-)).
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
my favorite example of a realtime system is payroll: Payday is a _hard_ deadline but the latency (time interval between inputs and outputs) can be days.
Bob
** Posted fromIn message , Bresco writes
Linux, like UNIX is not really an RTOS . As for latencies those figures only mean something when you are doing comparisons on the same hardware.
Do you need and RTOS? a lot (most?) embedded systems don't use them. In fact I would go so far as to say the default is not OS and you only go to one if you really need to.
An OS is more SW which needs more memory and power and requires a lot more checking. It adds complexity.
Also you need determinism as much as latency.
No. The correct latency is the best. Real time means on time. You don't need a Ferrari to go shopping in town on a Saturday.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
It supports most (not all) of the CPUs listed in arch: $ ls -F linux-2.6.26/arch/ alpha/ blackfin/ h8300/ m32r/ mips/ powerpc/ sh/ um/ xtensa/ arm/ cris/ ia64/ m68k/ mn10300/ ppc/ sparc/ v850/ avr32/ frv/ m68knommu/ parisc/ s390/ sparc64/ x86/
Why not?
Why not? We do. You can work with it like every other Linux system, plus some userland threads/processes or kernel threads are working with realtime capabilities.
You only need the latency your application specifies. The main feature of a RTOS is to guarantee this latency independent what happens else in your system.
jbe
That is not a particularly wide range and is mainly large MCU. However it is still not an RTos.
God question.
Which is not RT
"Some" so it is not a real RTOS. BTW I have not worked on Linux but I have worked on UNIX which is also not a real RTos
Yes... So a 60 second latency might be acceptable. :-)
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
*Linux* is mainly for large MCU - it requires a 32-bit cpu, memory measured in MB, and preferably an MMU (though you can do without if necessary). It is a much wider range of cpus than any other *large* OS I have heard of. Remember, it is not comparable with something like FreeRTOS (which would, of course, be a far better match for most projects that require controlled latencies and RT behaviour).
"God" question?
I read this as helix claiming that RT-Linux was not flexible, and Juergen asking what he considers inflexible about RT-Linux. I haven't used Linux for any real-time work myself, but I too am curious as to what helix considers inflexible about it.
Correct - many tasks in many systems do not have critical time constraints. Often you will split a system into a critical part that has RT constraints, and a more general non-critical part. One way to handle such splits is to have a dedicated microcontroller for the critical parts (running a "pure" RTOS like FreeRTOS), and the general part running something else (such as "normal" Linux). Using one of the several RT Linux systems gives you another option - run the non-critical parts as normal non-RT Linux processes, and run the critical parts as RT processes.
Linux is not UNIX - they simply have a wide area of overlap in system philosophy and API.
And having *some* processes or threads running with real-time constraints *does* make it a real RTOS. You run real-time tasks with real-time priorities, and non-real-time tasks without worrying about precise or controlled latencies. That applies regardless of what OS (if any) you use in your real-time system.
Yes.
You lot are daft as hell.
It is pretty obvious to any Firmware Engineer in commercial sector why Linux + RT is inflexible as hell.
It would be pretty bad if my employers and bill payers realised that they pay for me to make my own set of spanners, screwdrivers, meters, calibration equipment, workbench, DSO, logic etc AS WELL as developing their products =85.. well it would be great fun, but sadly I (and my girlfriend) like to eat most days :)
Anyway =96 how come most of you have time to have long lengthy arguments about using crappy tools instead of actually getting on with the development? No wonder the Chinese now own US and (shortly) Europe.
P.S I will be helpful and suggest the OP to read this to appreciate development concepts around =91strict real time=92 (as freeRTOS calls them here) :
That's nice, but are you going to answer the question? Here I'll re-quote and attribute it for you.
So, why do you consider RT-Linux inflexible?
-- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." "Already Gone" by Jack Tempchin (recorded by The Eagles) The Beatles were wrong: 1 & 1 & 1 is 1
In message , helix writes
Actually the top for owners of the USA are in descending order:
China Arabs Canada Mexico.
Yes, Canada and Mexico are 3 and 4 globally in owning the USA.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
They're sure going to be pissed off when they find out what we've done to the place...
-- Grant
I don't think so. It was not done by the US. Other people have been pulling the strings for a year or two. It is no coincidence the crunch came right on a US presidential election.
The US lost WW3 without even realising it had started let alone seeing the enemy
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Actually, by far the majority of the US, both in terms of physical assets and in terms of national debt (T-bills), is still owned by US citizens.
And this all has what to do with "latency needed in an RTOS"?
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.