MontaVista Linux claims that is has narrowed the real-time gap for Linux. The embedded Linux maker announced that is has successfully developed native, hard, real-time developments for the Linux kernel.
MontaVista Linux claims that is has narrowed the real-time gap for Linux. The embedded Linux maker announced that is has successfully developed native, hard, real-time developments for the Linux kernel.
Great work!
Still, more work awaits real-time Linux. Morgan said the company needs to improve the capabilities of the synchronization primitives in the Native Posix Threads Library in order to provide the full feature set expected and required by users of such systems as Solaris, HP-UX and AIX in telecommunications applications.
Git R Dun! so i can fully jump on the linux band wagon.
I believe MontaVista previously submitted some RT patches and Linus decided that they were not important for the mainline kernel. It is possible that this work was pre-NPTL, and that this is a much more comprehensive patchset.
This takes me back to my days programming semaphores and waitqueues for XScale boards.
I believe MontaVista previously submitted some RT patches and Linus decided that they were not important for the mainline kernel.
Wise move. At some point in time you have to say enough is enough to every special purpose #ifdef patchset in mainline.
These numbers are totally bogus. I’ve been involved in Embedded systems for 20+ years. Numbers like these are not valid, unless they are quantified in context.
More details here:
http://www.linuxdevices.com/news/NS6395401765.html
I also read they claimed 98 usec latency. Whoopee! Other RTOS’s can do this < 25 usec. The real question is: On what platform and subsystem?
Of course you can get fast response on a 4 GHz P4, but try that on a 200 MHz ARM. Different ball game. Most “deeply” embedded systems use processors < ~ 400 MHz, so “real time” with Linux is out of the realm of possibilities, there’s just too much code to deal with, as MV pointed out. And don’t forget, Linux started life as an X86 system, so running on a MIPS, ARM, or PPC, there are “hooks” here to compensate for the “intelness” of the Kernel.
It would be interesting to see some RT numbers vs. say NetBSD, which has a more well defined HAL and should therefore present better possiblities for optimization per platform.
A good accomplishment, no less, and maybe this time the work might find more acceptance in the “mainstream” Linux kernel, to help the desktop performance, etc. But compared to other RTOS’s still out there, they have a long way to go.
Other RTOS’s? In my book linux is NOT a RTOS. MontaVista is moving Linux in that direction but it is not a priority for Linus. If you can find one other OS that is not a mainly a RTOS that delivers the same type of performance I would be surprised.
As far as I know MontaVista is after the people that need a complete OS that is also a RTOS not the people that need an RTOS that needs not be complete.
Ingo Molnar (RH) and his guy did most of the work.
After LWN wrote about it they admit:
http://www.mvista.com/products/realtime.html
Kudos to MontaVista for developing developments. I guess it’d be kind of disappointing if they didn’t.
Reminds me of how Microsoft innovates innovating innovations.
I wonder why so many are interested in real-time or embedded Linux. Why not using eCos or RTEMS instead ? Both are open source and were *designed* for such purposes. Is it just because ‘Linux’ is a cool buzzword that will make any company building its products around it rich, cool and famous or am I really missing something important ?
Jack of all trades, master of none.
The special thing about Linux is the built-in networking and all the applications already ported to it. Typically real-time is needed to service certain high-priority devices, but there is stuff running in the background which could can plod along in whatever percent of the CPU is left.
But, it would be really neat if all this real-time Linux could run on a small processor without much overhead. I looked into MonteVista a few years ago and they are aiming at higher end processors. Most of the embedded world (even the 32 bit embedded world) uses lower speed processors without an MMU. Yes, I know about uclinux, but so far its not combined with hard real time.
Great job! What took you so long
In a lot of the consumer electronics embedded Linux world, there’s really only one or two applications that need real-time responses. The other applications don’t need it. With Linux, you have a large base of other applications to choose from.
Actually, wasn’t eCos a Linux derivative from RedHat?
> Actually, wasn’t eCos a Linux derivative from RedHat?
No, eCos was (mostly) written from scratch by Cygnus Solutions (which indeed was bought by Red Hat a few years ago; but Red Hat dropped it). Its two TCP/IP stacks (a new one and a older one) are OpenBSD’s and FreeBSD’s TCP/IP stacks.
And don’t forget, Linux started life as an X86 system, so running on a MIPS, ARM, or PPC, there are “hooks” here to compensate for the “intelness” of the Kernel.
No there aren’t.
It would be interesting to see some RT numbers vs. say NetBSD, which has a more well defined HAL and should therefore present better possiblities for optimization per platform.
Actually, Linux has been ported to more CPU architectures than NetBSD, and is much more flexible in the types of architectures it can run on (for example, systems without MMUs, that NetBSD doesn’t run on).
What’s more, NetBSD doesn’t even have rudimentry support for RT scheduling, nor has it had much work on getting interrupt latency down.
I’m not trying to say Linux is a realtime operating system, but let’s cut the FUD, shall we?
> Actually, Linux has been ported to more CPU architectures than NetBSD, and is much more flexible in the types of architectures it can run on (for example, systems without MMUs, that NetBSD doesn’t run on).
There is quite a difference between having been ported to different architectures and being officially supported on different architectures (every OpenBSD release is built and tested on the 16 architectures the project supports).
>There is quite a difference between having been ported
>to different architectures and being officially
>supported on different architectures (every OpenBSD
>release is built and tested on the 16 architectures the
>project supports).
You mean NetBSD?
Anyway, while there may be quite a difference, I don’t see how that has any bearing on the topic. All in-tree architectures in Linux are officially supported, and those are the only ones I have counted.
There is for example, the vax Linux port, but that isn’t in tree and of course I don’t count that as one of the supported architectures.