RT Linux Patches

sally bitter writes "Linux 2.6 kernel Real-Time? It is going to happen soon. Montavista developers submitted patches today to LKML to begin testing all the low latency task preempt and interrupt stuffs they're introducing."

Desktop Usage?

[Anonymous Coward]

Will this affect desktop usage for the better?

Benefits?

[0racle]

Would the benefits of this be just for embedded devices, or would more traditional uses also benefit from these changes?

I wonder if it's true real-time

[AaronW]

Where I work we did a project using Timesys Linux which implements true real-time support and has some really cool scheduler options. For example, with Timesys, you can, for example, guarantee that a task will get a minimum of 15.7ms execution time every 31ms. It even allows you to set priorities for interrupts, such that an interrupt can be scheduled at a lower priority than a user thread. And finally, they added support for priority inheritance to avoid the problem of priority inversion, which occurs when a low priority thread has acquired a semaphore and a high priority thread blocks on it.

Not only can you reserve CPU bandwidth, but also network bandwidth. Of course it also has all the other standard features one would expect of a real-time OS.

Sadly, Timesys has not applied their patches yet to the 2.6 kernel at this time.

-Aaron

Does RT == Better Synch?

[flushtwice]

Will Flash animation files finally have audio and video synchronized? Of course I'm actually starting to believe they are all probably out of synch for stylistic reasons... Anyone else get that way too?

Re:Benefits?

[iotaborg]

It is also very useful in science/engineering fields. At my lab, we use RTAI linux currently, and this allows us to acquire data from our systems in real time, giving us a reliable way to compare our data with time in our systems.

Re:Good news, folks

[drinkypoo]

If you're stripping out the parts of the kernel that you're not using and you're only running a single process or doing everything through drivers/modules, there's very little to go wrong. Linux's broad hardware support using the same source tree must be quite appealing to any developer, since their project can be "trivially" moved to basically any other processor that has enough power if they decide they want to switch. Your most highly-optimized code will probably always be written in assembler or in very very simple C that takes the hardware into account and uses few functions not defined in the program itself, focusing mostly on direct hardware access, but this will be a minimum of the project in general.

What is Real Time exactly?

[Elecore]

Can this be run on my Pentium4? What is it?

Re:Time to be a troll

[deanj]

It completely depends on what they mean by "real-time', since it depends on a whole bunch of things.

Personally, I'd be satisfied if they (or someone) semaphored everything at a low enough granularity to allow multiple processes in kernel context at the same time.

Modcomp did that back in the late 80s or early 90s, and their real-time UNIX kicked ass (Real/ix). Too bad that company's not doing much with it now.

Re:Responsiveness

[WillerZ]

Understand this:

These and other real-time patches do not reduce the average time required to do a system-call on your system (they probably increase it slightly).

Real-time priority only has an absolute meaning if you have a single-process system.

What real-time means is that a process or thread with a real-time scheduler (SCHED_RR or SCHED_FIFO) and higher-priority than any other process/thread in the system will complete its work in the shortest possible time. You can use the POSIX real-time calls to eliminate multiprocessing: set the scheduler to SCHED_FIFO and the priority to max on every process in the system and bingo, batch processing.

If you want your gnome or kde desktop to respond more rapidly, you probably need to make several processes real-time. The more real-time processes you have, the less real-time means -- if you set everything to realtime priority you're back to where you are now. Judicious use of SCHED_RR and balancing priorities might net you some improvement, but probably not enough to notice.

There are possibly some benefits to making multimedia apps such as xine run real-time, but unless you have playback problems now you won't notice the difference.

Phil

Re:Benefits?

[Nazadus]

My employer had to choose Windows over Linux becuase Linux lacked true realtime support. Windows doesn't either, however their is third party software and developing projects is (supposedly) easier with Windows. Our sales dudes also wanted to be able to say "We use Windows!"... We looked at Linux but Linux was just too slow. We are currently moving away from QNX 4.25 (yeah, I know... really old... we are even on the f patch... I finally convinced them to goto g for the server, so I could do backups.. otherwise cp would crash after 64k of files...). We currently build custom industrial robots, so we *have* to have real time or else things could suck. Although I think Linux is a while from where Tenasys InTime (our current third party software) level, it's nice to know people are still working on it... so Linux may become a chance in 8 or so years... when we want to move to another platform. I wonder if the medical field would be intersted in RT Linux... I don't know if they require some special stuff because of legallity or something though...

Re:Desktop Usage? Why not?!

[faragon]

Actually, there are RTOS UNIXes running desktops. From three years ago, I'm used to run the Posix Desktop over LynxOS 3.0.1 (nowdays on 4.0.0), running gvim, emacs, xmame, and so on. The only missing thing was USB and sound card support (still not supported on v. 4.0.0). There is also XFree support, at least for LynxOS, but may be too for QNX et al.
There are, of course, disavantatges, you can not archieve the same disk throughput on current RTOS compared to Linux or Windows. From my experience, both ethernet and IDE throughput it's far from being optimal on a RTOS (think about 60-80%). But that it is commonsense, if you want kick ass response times, you'll lose a bit of throughput and viceversa.
There is other important points, usually, on RTOS the disk-cache has a fixed size, processes are limited to a relatively low number (usually 100 to 500), and many other limitations.

The resume it's quite easy, if you want to have a RTOS you should be sure you have, at least:

1) Preemptible kernel
2) Inverted priority detection (to avoid thread stalls; this point it is not 100% solved on most commercial RTOS)
3) Acotated resources
3.1) Deterministic disk cache (usually fixed length on most -current- implementations)
3.2) Limited process handling (that point may will be specially good for Linux and the O(1) scheduler, as other RTOS have poorest scheduling scheemes; could be amazing having thousands of threads without penalization... beating commercial RTOSes (!))

(This thread it's amazing, but I'm tired; 2:30 am here, I have to leave without adding a more complete comment, sorry).

Re:Responsiveness

[Anonymous Coward]

There's one very big field of use in using linux as audio platform. Previously Ingo Molnar's Voluntary Preemption patches and now also this RT linux stuff (which seems to partly build on top of the VP stuff) enable linux users to run audio applications with latencies down to the sub 1ms range.

Threaded and nonthreaded IRQ handlers are available with Ingo's VP patches today. Average kernel latencies around 10 - 80us are possible today, too. No garantees made about the worst case though with VP, but in day to day use i seldom see a non preemptible critical section longer than 200-300us.

And with the help of the realtime lsm which enables (certain) non root users to use the SCHED_FIFO scheduler class (and to mlock application memories), linux beats the sh*t out of ms windows and is easily on par with mac os x wrt to achievable latencies.

Jackd and other linux audio apps are still a bit rough and sometimes a bit buggy, but stuff is really starting to stabilize and get really really useful.

Man, i waited 10 years for linux to become my ultimate audio workstation OS and now it's finally happening. RT linux will only make it even better!

P.S.:

Check out the apps section on the JACK pages to see what's available today:

http://jackit.sf.net/apps

Re:Not a problem anymore

[flushtwice]

Actually, I am using version 7 right now. Got it as soon as it was available in fact. I'm also using alsa sound since I upgraded to Mandrake 10. The OSS was just dropping out completely on me under 9.1.

Most of the time I don't have too much trouble with it, but it doesn't synch up. Having seen a few of these files on someone else's computer, it's made it all the more obvious to me.

Someone above you mentioned that it was Macromedia's fault, and that may be. With each release, the player seems to get a little better (at least they are watchable on sites like Newgrounds and Atom Films now), but the audio and video still don't line up quite right.

Of course Judging from the mod slap I just got, I get the impression that RT Linux wouldn't be the right tool to solve audio synch problems in such cases...

Re:they can dream

[AaronW]

I'm not sure I would call VxWorks a microkernel. In VxWorks, everything is in the same address space. There's basically no memory protection (unless you count the bastardized VxWorks AE). Think of VxWorks as the ultimate monolithic environment, where everything goes into the kernel.

Re:Good news, folks

[provolt]

Linux has been evaluated and certified for safety critical applications. LynuxWorks [lynuxworks.com] and Rockwell Collins [rockwellcollins.com] worked together to certify a specific Linux kernel and distribution to
DO-178B Level A certification.

DO-178B is the standard for software on commerical aircraft. It's difficult and expensive to do, but it's required by the FAA. Level A is the highest level of certication. Level A certification is required for critcal components like the displays, fight controls and the auto-pilot.

There really aren't any software certification standards that are more rigorous than DO-178B, and Linux already has been certified.

Re:Medical and aviation already using Linux

[Nazadus]

Could you give some quantifiable reasons why you think Tenasys is in violation of the RT Linux patent?

Re:Benefits?

[grozzie2]

hehe, 'not tolerated' is actually a considerable understatement. A Level D sim actually has to be run thru a validation sequence on a daily basis. That sequence must validate that the skew between display motion and platform motion is 100ms or less (its 200 ms for a Level C device). I cant remember offhand the skew allowed between control input and start of motion, but I belive it's also on the order of 'within 200ms of the response of the aircraft being simulated', with the aircraft values taken from in flight measurements. I've been in them a couple of times when the display/motion is out of wack, and it's really quite an awful experience, really the only time I've ever suffered from 'airsick'. 29 years of flying, an airpane has never made me sick, but the simulator has done it 3 times.

I've flown a lot of sims over the years (annual recurrency for multiple types adds up to a lot of simulator time). I'm really curious now who's building them on linux, wondering if I've actually flown one of those.

Re:Time to be a troll

[JKR]

Ahem.

Real time linux is NOT "a true RTOS running linux as its lowest priority thread." That doesn't even make sense! You've obviously never done any kernel programming, or bothered to do any basic knowledge gathering on operating system design at all.

Perhaps you might like to tell certain large Japanese A/V companies about that, since they do EXACTLY that (run Linux as a task under a uITRON RTOS). I think you maybe need to learn something, too.

Jon.

NTP = Insecurity

[Anonymous Coward]

The NTP protocol is over-engineered for what is fundamentally a relatively simple problem. The NTP implementations 4.2.x have at least two -- probably many more -- currently unreported heap and buffer overflows which should be remotely exploitable.