Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

RT Linux Patches

timothy posted about 10 years ago | from the quitcher-laggin dept.

Operating Systems 170

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

Sorry! There are no comments related to the filter you selected.

Desktop Usage? (1, Interesting)

Anonymous Coward | about 10 years ago | (#10482124)

Will this affect desktop usage for the better?

Re:Desktop Usage? (0)

Anonymous Coward | about 10 years ago | (#10482267)

Probably just as much as all the other kernel features that reportedly do to everyone else (OMG IT TOTALLY BLOWS WINDOZE OUT THE WATER NOW!!) but suspiciously make no difference when I try them, Like pre-empting.

Re:Desktop Usage? (2, Informative)

meowsqueak (599208) | about 10 years ago | (#10482426)

Probably not - realtime operating systems are primarily for embedded systems, not desktop systems. Think 'if this task doesn't run in the next NN microseconds then [hundreds of people will die]/[millions of dollars will be lost]/[the software will crash]/[bad things will happen]/[etc]'...

Re:Desktop Usage? (2, Funny)

JVert (578547) | about 10 years ago | (#10482478)

THAR IS BOMB ON COMPUTAR

everyone stay calm, if the game drops below 55 frames per second this user will die. Or at least kill alot of people in a fit of rage.

What is the name? (0)

Anonymous Coward | about 10 years ago | (#10483211)

When we say Linux then we are saying GNU/RT-Linux.

open4free ©

Re:Desktop Usage? Why not?! (5, Interesting)

faragon (789704) | about 10 years ago | (#10482624)

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).

Frist Prost! (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10482128)

first bitches! Oh yeah eat the peach mofos!

Re:Frist Prost! (5, Funny)

The Clockwork Troll (655321) | about 10 years ago | (#10482169)

Your attempt was pre-empted by a higher priority post. I guess the RT patches work.

Re:Frist Prost! (1)

Chris_Mir (679740) | about 10 years ago | (#10482831)

Seems your 'r' is also pre-empted and echo-ing as a side effect.

Benefits? (2, Interesting)

0racle (667029) | about 10 years ago | (#10482132)

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

Re:Benefits? (4, Informative)

CaptainFrito (599630) | about 10 years ago | (#10482192)

There are a few non-embedded applications that would indeed benefit. Automated test and measurement is one that I can think of right off the bat. RT probably the last big advantage to VxWorks, so maybe now's a good time to dump your WindRiver stock.

Re:Benefits? (5, Interesting)

iotaborg (167569) | about 10 years ago | (#10482204)

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:Benefits? (5, Informative)

mdlbear (735185) | about 10 years ago | (#10482399)

The main beneficiary of the low-latency patches will be multimedia -- audio and video demand consistent scheduling and minimal interference from interrupts. (That's why many audio workstations are still running on Windows 98.)

Re:Benefits? (5, Interesting)

Nazadus (605794) | about 10 years ago | (#10482524)

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:Benefits? (1)

Nazadus (605794) | about 10 years ago | (#10482568)

I forgot to add, XP Embedded also allows you to cut stuff out. So the Linux being modular doesn't help very much in this case... (Aside from the monetary value)

Medical and aviation already using Linux (1)

r00t (33219) | about 10 years ago | (#10482691)

Dude, Linux scans your brain!

There are indeed legal issues, but they are
solvable. The FAA now lets Linux do everything
except operate the controls. The FDA is OK with
various X-ray things made by Siemens Medical.

I suspect your Windows RT provider is in violation
of the RT Linux patent. What will you do if they
get sued by TimeSys and discontinue the product?
You'd be much safer using Linux. At least then,
your code would stay portable. You wouldn't need
to worry about losing your ability to ship product
so much -- worst case, you choose another one of
the many UNIX-like systems. For Linux alone you
can choose: TimeSys RT Linux, RTAI, Montevista's
Hard Hat Linux, Concurrent's Red Hawk Linux, and
of course roll-your-own Linux.

Whats this mean? (-1, Redundant)

Anonymous Coward | about 10 years ago | (#10482133)

So whats this mean to Anonymous Cowards using Linux?

Real time? (4, Funny)

Eudial (590661) | about 10 years ago | (#10482139)

Does this mean i won't have to adjust my clock any more? ;)

Re:Real time? (1)

3D Monkey (808934) | about 10 years ago | (#10482364)

Not if you were on surreal time to begin with..

Re:Real time? (5, Informative)

flok (24996) | about 10 years ago | (#10482407)

For that, you should use NTP [ntp.org] .

Good news, folks (3, Informative)

drinkypoo (153816) | about 10 years ago | (#10482145)

Combined with the ability to remove portions of the linux kernel that you aren't use, this is one more step toward world domination by Linux. Currently the same linux kernel can be used for everything from non-realtime embedded projects (typically implying a certain amount of horsepower, but these days, not an MMU!) up to NUMA-based multiprocessor workhorses. With Linux running (or capable of running) on many of the most powerful systems on the planet it is easy to forget about the other end of the spectrum which is no less important. This is a step necessary to get Linux into applications like engine management systems, besides the applications (like GPS) cited in the linked article.

Re:Good news, folks (5, Funny)

WillerZ (814133) | about 10 years ago | (#10482217)

I, for one, don't like the idea of Linux running as the OS for my engine-management system.

The first pile-up after they're introduced and slashdot'll be covered in "So that's what a beowulf cluster of Linux EMUs looks like".

Re:Good news, folks (2, Interesting)

drinkypoo (153816) | about 10 years ago | (#10482261)

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.

Re:Good news, folks (2, Insightful)

WillerZ (814133) | about 10 years ago | (#10482299)

...there's very little to go wrong.
"very little" is more than I want to be going wrong in my car at 70MPH. Phil

Re:Good news, folks (1)

drinkypoo (153816) | about 10 years ago | (#10482381)

The issue is that these things are getting more complicated all the time and eventually they're all going to end up using operating systems because the amount of power they use is only going up. The companies are kind enough to segregate your average car's functionality into several separate computer modules because they know that the world is a harsh place and they're cheaper to replace that way but in the interests of reducing the price of the car all of those computers are eventually going to be some tiny computers that read sensors and put data on a low-voltage or even fiberoptic bus (using fiber would be beneficial primarily for the electrical isolation provided, not because a higher level of bandwidth is needed) and all of it is going to go to a central computer which will handle all of the management functionality of the vehicle. It's only a matter of time, really. Wouldn't you rather that computer be running Linux than NT/Embedded?

Re:Good news, folks (3, Insightful)

WillerZ (814133) | about 10 years ago | (#10482506)

Not necessarily. Those aren't the only two choices: Realtime Solaris and QNX RTOS are also possibilities. Even better, they could stop trying to add DVD players to my engine-management unit. I don't feel there's anything compelling missing from my current car, which has a number of separate systems and a fairly simple (so far as I can tell) EMU which co-ordinates their efforts,

The linux (kernel.org) codebase is not really stable enough to meet the needs of embedded systems. If someone wants to build an embedded controller for a car they'll need a stable embedded OS for at least 9 months before they start production -- 6 months to write the software and testcases, and 3 months to test and debug at a minimum. During this time, there is no benefit to selecting linux -- you aren't getting the new features because you've frozen the kernel; however, there is a downside to selecting linux -- bugs which surface later (perhaps in the testing phase) will not be fixed in the form of a patch to your level.

That suggests you need to buy your linux embedded from a commercial venture, to ensure it's supported. At which point, linux needs to be judged against the commercial competition; it will probably lose that battle because the commercial ones will be certified compliant to a myriad standards, and linux won't be. Certification is important to establish a chain-of-blame should anything go wrong.

Phil

Re:Good news, folks (1)

drinkypoo (153816) | about 10 years ago | (#10482593)

While I recognize the validity of your points I do think Linux can be successful even given those considerations. I do not think it is impossible for someone to develop a certified realtime linux for which support costs money, provided they can get sufficient contracts to pay for certification testing. There is still a benefit in that most of the work has been done for them. At this point it's [mostly] bug fixes, testing, and more bug fixes, followed by more testing, et cetera ad infinitum.

Each new kernel version can bring a new version of the product, with the upgrade coming well into the new kernel's life. Obviously it's not necessary to follow the Linux release schedule.

Re:Good news, folks (2, Insightful)

WillerZ (814133) | about 10 years ago | (#10482724)

I agree. It would probably now be easier for a company with an existing RTOS which is massively out-of-date to dump that and fix-up linux, rather than develop their own product further. New entries to the market will still find it very difficult as the path to certification is painful if you haven't trodden it before.

I hope this happens, as a lot of the work they would need to do to get certified would benefit desktop linux, particularly in the realm of hardcore POSIX conformance.

Phil

Re:Good news, folks (2, Insightful)

WillerZ (814133) | about 10 years ago | (#10482275)

On a serious note, the design decisions for a general-purpose desktop/server OS are very different than for a safety-critical embedded system like an ECU. There is often no reason to have a pre-emptive multitasking OS in application-specific systems, as they only do one thing.

There are embedded OSs for which every line of code has been checked and audited. I think that's a good thing where lives are at stake. For Linux to meet those requirements would require a massive slow-down to the development effort, which would reduce how useful it is as a desktop platform.

Phil

Re:Good news, folks (1)

sloanster (213766) | about 10 years ago | (#10482808)

So are you saying that you're a luddite, or that you'd be more comfortable with something like ms windows? (gives a whole new meaning to "crash" and "blue screen of death" doesn't it?)

Seriously, I can't think of any OS I'd trust more than linux for the really critical stuff.

Mod parent down, -1 troll/-1 clueless (1)

WillerZ (814133) | about 10 years ago | (#10483151)

So a blue-screen is worse than a panic now?

There are operating systems other than Windows, Linux, *BSD, Unix, MacOS, OS X, OS/390 and z/OS which are far better suited to running the software which controls my car than any of the aforementioned.

This is because an OS designed from the ground up for real-time, safety-critical tasks will always beat an OS designed for running word processors, compilers, business applications, games, or multimedia editing software when it comes to controlling my car.

Phil

Re:Good news, folks (0, Offtopic)

sn0wflake (592745) | about 10 years ago | (#10482287)

This is not a troll post. I don't think Linux will dominate the world as long as some games, like The Sims 2, doesn't work. Check out Transgaming [transgaming.com] for more information.

O/T: Linux gaming (0, Offtopic)

WillerZ (814133) | about 10 years ago | (#10482325)

It may not be a troll, but it is off-topic.

Continuing the same off-topic-topic, I have a question: Are there figures on the percentage of PCs used to play games? I get the feeling most of the companies pushing linux are pushing it for business use, which suggests that the business market is larger...

Phil

Re:Good news, folks (1)

jericho4.0 (565125) | about 10 years ago | (#10482377)

(OT)

What is this constant facination with the desktop? People switch to Linux when they get sick of Windows. Developers sometimes contribute to it. Linux gets better. What does it matter what % of the market linux holds?

And most people who buy and use computers are not gamers (suprise!), although games do have a driving effect on linux development.

Mod parent up pls (1)

WillerZ (814133) | about 10 years ago | (#10482525)

Good question. Answer: it doesn't. Unless you're RedHat, Novell, IBM, or one of the other organisations with a commercial interest in it.

The problem, as I see it, is that we need these guys on board because they plough a lot of resources into linux and that ultimately benefits us. Thus we need to pretend that the market-share of linux matters, while continuing to realise that it's a worthless metric.

Phil

Re:Good news, folks (1)

drinkypoo (153816) | about 10 years ago | (#10482418)

I agree that Linux cannot dominate without more attention being paid to gaming. However, I go a step further than you do, because I think it can't do it while you need special software to actually play the games. The games are going to have to be Linux native before it can really happen. I figure the way to get there is to use Linux on gaming platforms. Someone should really do a game console that runs Linux, uses OpenGL and SDL to do its output, and which has hardcore DRM, as much as I hate to say it, because if it doesn't people will never pay for a single damned game. We saw it happen to Dreamcast, and while that wasn't the only thing that killed it, it had to hurt. Piracy never really affected the Sega CD, which has no copy protection at all, because no one had CD burners.

Anyway the Xbox is just a way to lock developers into the Microsoft world, because soon the games that you write on Xbox will be portable to Windows without any effort whatsoever, and the Windows games will be portable to Xbox without too much trouble either. That's going to be a strong lure for many developers, and the more power they get this way, the more developers they can browbeat into making games exclusively for their platforms.

Now is the time for a Linux-based game console. If Infinium labs ends up self-destructing like I figure it will, maybe someone can buy their wreckage and use that hardware and their contacts to develop the platform, but I suspect it'll be hopelessly dated by the time any legal encumberance is gone, so an independent effort is called for.

what will LINUX look like in 2010? (-1, Offtopic)

BlackShirt (690851) | about 10 years ago | (#10482173)

your (wild) guesses

Re:what will LINUX look like in 2010? (1)

BlackShirt (690851) | about 10 years ago | (#10482191)

op. system that boots in a second (would be quite useful for a home user) :)

Re:what will LINUX look like in 2010? (0)

Anonymous Coward | about 10 years ago | (#10482441)

When my computer boots, it's mostly just the harddrive grinding. Unless the kernel can make my harddrive spin faster, I doubt you'll see much change in boot times.

and (1)

BlackShirt (690851) | about 10 years ago | (#10482233)

RT LINUX will be used for what?

Re:what will LINUX look like in 2010? (4, Funny)

0racle (667029) | about 10 years ago | (#10482328)

Windows.

Re:what will LINUX look like in 2010? (0)

Anonymous Coward | about 10 years ago | (#10482965)

Windows 2015 that is!

I wonder if it's true real-time (5, Interesting)

AaronW (33736) | about 10 years ago | (#10482180)

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

Re:I wonder if it's true real-time (2, Informative)

AaronW (33736) | about 10 years ago | (#10482239)

I hate to respond to my own post, but reading the article (what, someone rtfa) it seems that they did add priority inheritance to the kernel mutexes avoid priority inversion. For proper real-time support, hopefully they also made this available to user-space threads.

-Aaron

Re:I wonder if it's true real-time (1)

Thing 1 (178996) | about 10 years ago | (#10482919)

with Timesys, you can, for example, guarantee that a task will get a minimum of 15.7ms execution time every 31ms.

What if three tasks told the system "I need a minimum of 15.7ms execution time every 31ms."

Would the third one get an error? (Well, the second should actually because after the first takes his chunk, there is only 15.3ms every 31ms.)

Just wondering how robust it is...

Re:I wonder if it's true real-time (1)

aardvarkjoe (156801) | about 10 years ago | (#10483247)

What if three tasks told the system "I need a minimum of 15.7ms execution time every 31ms."
I refuse to be impressed until it can give the time to all three.

When will these be merged? (2, Insightful)

Adam Avangelist (808947) | about 10 years ago | (#10482185)

Do you all think these will be merged and ready before 2.6.9 is released?

Re:When will these be merged? (2, Insightful)

Anonymous Coward | about 10 years ago | (#10482253)

When it's tested, and works. And when Al Viro are done with
his rants over the code.
My bets are by 2.6.18, any takers ?

Re:When will these be merged? (1)

stor (146442) | about 10 years ago | (#10483063)

Hehe I don't think so :)

According to the announcement the patches cause failures during high load and low memory conditions. There are other known problems.

These patches will require a lot of vetting before they're merged imnsho. They'll probably spend a few months in -mm in the very least.

Cheers
Stor

Wait a sec (0, Troll)

Code Dark (709837) | about 10 years ago | (#10482187)

Wait a sec... if the kernel updates itself in real time (if I'm reading this correctly), wouldn't that make everything very unstable? Without ample testing, the rock-solid linux kernels would be bug-riddled and unreliable. On the other hand, the kernel _fixes_ would come instantly too... this is a very interesting concept.

Re:Wait a sec (1)

jericho4.0 (565125) | about 10 years ago | (#10482396)

Well, we're either about to throw away 10 years of work to get a stable kernel, or you read it incorrectly.

Re:Wait a sec (1)

Code Dark (709837) | about 10 years ago | (#10482434)

I'm not saying that we'd throw away the kernel, but rather that if it updates itself there may be bugs in the patch itself.
But I probably misread parts of it, too. Sorry for any confusion.

Re:Wait a sec (0)

Anonymous Coward | about 10 years ago | (#10482409)

[Reuters] At 7:29PM on Saturday, October 8th, geneticists at the University of Southern California released evidence that shows conclusively that the world had officially created a better idiot, as per the idiom, codenamed "Project CodeDark". This news comes just hours after the second nationally-broadcast presidential debate, leading some to draw the obvious connection between the two. Film at 11.

Re:Wait a sec (0, Offtopic)

WillerZ (814133) | about 10 years ago | (#10482586)

How did he get 0, Troll and not +4, Funny?

Okay it might mislead newbs, but this is /., AOLers are gonna be confused enough anyway.

Phil

Does RT == Better Synch? (1, Interesting)

flushtwice (802474) | about 10 years ago | (#10482197)

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:Does RT == Better Synch? (1, Informative)

Anonymous Coward | about 10 years ago | (#10482249)

Every video player out there can sync sound and video on linux. If they can do it just fine with today's kernel, why would flash be so special?

Cleary it's sloppy programming on Macromedia's part.

Not a problem anymore (1)

Kristoffer Lunden (800757) | about 10 years ago | (#10482500)

Since version 7 the audio and video has no synchronizing problems that I've seen, and that is on various boxes. It was a big problem with v6 though, maybe you want to try and upgrade? It has been available for months now...

Another possible reason would be if you are using arts or esd. Sound daemons can mess up sync pretty badly, never ever got it to work properly with mplayer or flash as examples, so now I'm using dmix instead. Which, in turn, has other issues, the one that annoys me being that I have to stop playing all other sound sources before starting firefox if I want to hear sound in flash movies. And no, piping firefox via various translating programs alsa/arts/oss you name it, does not work. Usually that just makes everything crash. ;-)

Re:Not a problem anymore (2, Interesting)

flushtwice (802474) | about 10 years ago | (#10483060)

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

RTAI Already Does this (0)

Anonymous Coward | about 10 years ago | (#10482242)

RTAI has provided hard real time support for the 2.6 kernel since may!

gethrtime() ? (1)

ScreamingSlave (626772) | about 10 years ago | (#10482273)

Does this finally mean Linux will have something like Solaris' gethrtime()?

Re:gethrtime() ? (2, Informative)

David M. Andersen (711958) | about 10 years ago | (#10482635)

Looks like it. [rtlinux.org]

This function is a non-portable RTLinux extension. gethrtime returns the time in nanoseconds since the system bootup. This time is never reset or adjusted. gethrtime always gives monotonically increasing values. hrtime_t is a 64-bit signed integer.

The actual resolution of gethrtime is hardware-dependent. It is guaranteed to be better than 1 microsecond.

Odd that RT Linux is the first hit in google actually.

Responsiveness (0)

Guidlib (814472) | about 10 years ago | (#10482285)

Fantastic news for the future of Linux's responsiveness. I can't wait to see things like X being improved significantly in terms of responsiveness because of this. It won't only benefit embedded systems.

Re:Responsiveness (2, Interesting)

WillerZ (814133) | about 10 years ago | (#10482405)

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:Responsiveness (1, Interesting)

Anonymous Coward | about 10 years ago | (#10482945)

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

What is Real Time exactly? (2, Interesting)

Elecore (784561) | about 10 years ago | (#10482289)

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

Re:What is Real Time exactly? (1)

Vint Cerf (713706) | about 10 years ago | (#10482419)

Yes, but only if you have Hyper-Threading enabled.

Re:What is Real Time exactly? (4, Informative)

0x0d0a (568518) | about 10 years ago | (#10483281)

Real time refers to a system where tasks completing by a certain deadline is more important than just about anything else. Real time systems are less efficient than non-real-time systems -- they trade efficient scheduling for bounded scheduling.

This is generally split into hard real time and soft real time.

In a hard real time system, if a task misses a deadline, the task has failed. You might as well not do it. This sort of thing is important for, say, control systems that determine what thrusters to fire when on the Space Shuttle.

In a soft real time system, you have some penality if a task isn't finished by a certain time.

One kind of real-time functionality that a system might provide (and Linux does and has for a while) is a "real time priority level". To simplify things a bit, when a process is marked as "real time", that process runs and every other process is ignored. This is important if that process has a task that *must* complete. As a negative side effect, it means that another task (which might only want a tiny bit of CPU time, just enough to keep copying a file from disk to disk) can't run at all and all the disk activity stops. As a result, the time required for all the work the system must do increases, and the system runs more slowly. However, the one process that *must* gets time continues to get it.

It's not something that a desktop or server user is going to benefit much from.

Time to be a troll (0, Troll)

Anonymous Coward | about 10 years ago | (#10482313)

Sorry to say that but, do you really want to use rtlinux? I mean, linux is not real time at all, it is too big (about 1Mb) and rtlinux is just a true RTOS running linux as it lowest priority thread. So, if you want to use some linux service, it is goint to be executed in the lowest priority level. At the end what you win?

I will stand using a true RTOS link=www.rtmes.com .

Re:Time to be a troll (3, Interesting)

deanj (519759) | about 10 years ago | (#10482403)

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:Time to be a troll (2, Funny)

B1gP4P4Smurf (790700) | about 10 years ago | (#10482600)

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.

RTFA. Or (god forbid) the code.

Linux has allowed multiple processes in kernel context at the same time for ages. It's called SMP and/or CONFIG_PREEMPT.

Re:Time to be a troll (5, Informative)

flithm (756019) | about 10 years ago | (#10482476)

Sorry to say but, you don't really understand the concept of real time.

First of all, an OS being RT has nothing to do with its size. It could be 18 terabytes, or 4 kilobytes and still qualify as real time, as long as it did a few things within certain thresholds.

To be a simplistic about it as possible, the only thing a real time operating system needs to do is to emphatically guarantee that it will respond to interrupts within a pre-determined amount of time. Even this time isn't exactly important, obviously it should be small, but as long as the time constant is known and guaranteed it qualifies as a real time operating system.

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.

Note that several companies/vendors/instutions have provided incarnations of real time linux in the past (and currently). They do this by modifying the kernel source to make sure program ISR's get called within a set threshold. For example FSMLab's RTLinux [fsmlabs.com] has a worst case response rate of 12 microseconds.

Real time operating systems are not for everyone. Your system will be slower, but will feel more responsive. Strict server operating systems such as FreeBSD, and the Windows Server class OS's have a much higher ISR response rate. Windows Server is as high as 120 ms. This is done on purpose! They do it to get every bit of performance out of the server they can. Remember, more ISR calls means more interruptions in the CPU pipeline, and more instructions executed per second. On a pentium 4 with its huge pipeline, interrupts are disasterous to execution speed.

Personally I welcome a real time freely available linux kernel. I wouldn't mind sacrificing a little speed for real time operation. If you've ever used a real time operating system, you know what I mean. It's a great experience. But having said that, most people probably won't want that. And that's fine... but having the option is great.

Anyway... before you spout your mouth off and try to sound like you know what you're talking about... learn something first!

Re:Time to be a troll (2, Insightful)

0x0d0a (568518) | about 10 years ago | (#10483220)

Your system will be slower, but will feel more responsive.

You do not need a real time system to "feel more responsive". In most systems, kernel locks simly do not tie things up for anything approaching human-perceptable times.

This stuff is important not for the server or the desktop, but things like control systems.

Re:Time to be a troll (1)

faragon (789704) | about 10 years ago | (#10482484)

First of all, RTLinux doesn't mean "Linux having RTOS" but "some weird trick^H^H^H^H^H^H^H^H^H^H^H software that runs Linux on his spare time, able to comunicate with it". After this puntualization, it is fair to say that RTLinux it is useful for a wide spread of applications requiring not only real time response but also very short response time; i.e., on 10-20 us requeriments, RTLinux it is still better than VxWorks or LynxOS, as has a very thin harness. By the way, in the real world, these critical tasks are driven by little MCUs (8 or 16 bit ones), not by an powerful 32 bit system. For 32/64 bits systems, driven by a UNIX (or UNIX-like) RTOS (real time operating system), you should have enough with 50 us to 10ms respose times.

Commercial UNIXes, as LynxOS, are able to give to you a table with a relation of response times for every aspect of the OS (scheduling, OS primitives, IRQ dispatching, etc.).


From my point of view, Linux has two major handicaps:

1) Archieve fully POSIX compliance in both process/thread identification/handling and inprocess signal routing (actually it is painful to migrate complex POSIX apps to Linux).

2) True hard real time response archievement; after this goal, winning the "RTOS" label (and bringing joy to my heart; sorry for the subjective parenthesed comentary).

What Real Time is and what you can do with it. (5, Informative)

Anonymous Coward | about 10 years ago | (#10482393)

Real time means that processes can have an absolute time where they have to be finished. Mainly, because that means they produce output, and that output is needed THEN, not 'later'. For example, an automatic flight manager in an airplane needs his data by time to adjust in time, and needs to run at least every once and then to check if everything goes well. If the 'system' has a lot of work to do and gives the automatic-pilot-process to little time, the plane WILL hit that mountain you're heading at. RealTimeOS's account for that and make sure certain processes are excecuted more often than others since they have an higher priority.

For the more techies: this is not like priorities in non-rt-kernels where an higher priority results in more timeslices in the round robin algorithm, it means that it isn't interrupted until it reaches a certain 'done'-state. And if a process depends on an other process (radar automatic pilot relationship-like) that process will be run prior to the automatic pilot process, to assure the automatic pilot gets new data, and no old data or old/new mixed data.

It is a nice addition to the linux kernel. Not very usefull for the every-day-workstation, but very usefull for the portability of it. A couple of whole new markets suddenly now have the possibility of choosing for linux. (unfortunately, those markets don't just 'switch', same reason as nasa using 8086's in their spaceshuttles)

- waccolodian.blogspot.com

Re:What Real Time is and what you can do with it. (0)

Anonymous Coward | about 10 years ago | (#10482657)

Would the realtime stuff benifit, say, digital music workstation?

Like when your mixing music and are trying to cooridinate all the different apps so that the output will be in proper sync?

Stuff like what the JACK plugin is suppose to accomplish.

So could you run JACK at the realtime priority and make sure that there is very little, or at least a set amount/predictable of lantency?

Seems it would be a boon for all those digital "disc" jockeys.

Soft real-time Vs Hard real-time (5, Informative)

WillerZ (814133) | about 10 years ago | (#10482667)

There are two types of real-time, soft and hard. This is how you distinguish the two:

Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".

The parent is talking about hard real-time scheduling, which is what these patches help with. Hard real-time has sharp deadlines, enormous penalties for missing a deadline, and (relatively) long periods between deadlines. Of course, there are short-deadline hard real-time systems, like ABS controllers in cars; however these tasks will usually be handled by dedicated hardware.

Soft real-time is a more interesting topic for desktop Linux, because you aren't usually in a situation where your desktop machine can kill you by inaction. Soft real-time has fuzzy deadlines, small or no penalties for missing deadlines, and (relatively) short periods between deadlines. DVD playback is a good example: if a frame is delayed by a small amount or even skipped entirely the viewer is unlikely to notice provided it doesn't happen too often. Same for games.

Phil

Re:Soft real-time Vs Hard real-time (1)

B1gP4P4Smurf (790700) | about 10 years ago | (#10483223)

There are two types of real-time, soft and hard. This is how you distinguish the two:

Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".


There is actually a significant and interesting grey area in between. Operating the control rods in a nuclear plant would clearly be hard realtime. Desktop audio playback imposes a soft realtime constraint (because there will be gaps if you dont keep up). But what about the Mt. St. Helens example mentioned in the article? Or, what about audio playback/mixing where you are connected to a sound system loud enough that a pop or a click would damage people's hearing?

Re:What Real Time is and what you can do with it. (1)

faragon (789704) | about 10 years ago | (#10482744)

For the more techies: this is not like priorities in non-rt-kernels where an higher priority results in more timeslices in the round robin algorithm, it means that it isn't interrupted until it reaches a certain 'done'-state. And if a process depends on an other process (radar automatic pilot relationship-like) that process will be run prior to the automatic pilot process, to assure the automatic pilot gets new data, and no old data or old/new mixed data.

My "techie" friend, RTOSes have, if you wish, and usually as default, round robin scheduling policies. A RTOS, and by extension, any OS, doesn't cares about your application, his main target it is to comply with their white paper specification. Id est, if the vendor say that their RTOS have a list of N response times for N circumstances, it is your responsability to solve your problem with the RTOS as a tool. The main and only difference between a RTOS and a non RTOS is that a RTOS gives to you a list of acotated response times related to the OS responsability, don't care if the units are microseconds or years. Of course, as example, if you have to deal with servomechanisms you'll need, at least millisecond precission. The quantification of the time response for a RTOS is the variable that allow that you could say "this RTOS, as tool, will work with my software application to solve the requested engineering problem".

Re:What Real Time is and what you can do with it. (0)

Anonymous Coward | about 10 years ago | (#10483164)

In particular, the summary seems to blur the idea. Realtime does not mean "low latency", it means "guaranteed latency." It's possible that a non-realtime system has lower latency, but not predictably. Sometimes that's more useful, sometimes not.

If .1% of the time your system clock is 30 seconds late but otherwise it's really accurate, that's ok. If .1% of the time your artificial heart beats 30 seconds late but otherwise it's really accurate, that's bad.

Re:What Real Time is and what you can do with it. (1)

Tough Love (215404) | about 10 years ago | (#10483346)

"It is a nice addition to the linux kernel. Not very usefull for the every-day-workstation"

Audio and video are realtime problems. Unless you have a realtime solution, you will never get rid of dropouts and stutters.

Compare this to Ingo Molnar's 'Voluntary Preempt' (1)

Theovon (109752) | about 10 years ago | (#10482451)

How does this patch set compare to Ingo's voluntary preempt patch set? Is one better than the other? Could they be combined in a useful way?

Re:Compare this to Ingo Molnar's 'Voluntary Preemp (5, Informative)

B1gP4P4Smurf (790700) | about 10 years ago | (#10482549)

This incorporates some aspects of Ingo's VP patches that are prerequisites for any kind of RT support the kernel. These include offloading all softirqs to ksoftirqd (normally softirqs run immediately unless the load gets too high in which case they hand off to koftirqd) and IRQ threading, which created a separate thread for each irq and offloads hardirqs (aka the "top half" of an interrupt handler) to that thread. If you stop here the latency is about as good as OSX.

This is where the two approaches diverge. The VP approach uses normal kernel preemption, with the addition of scheduling points with optional lock break inside spinlocked code. But you still cannot preempt code that is holding a spinlock. This becomes the lower bound on latency.

MontaVista goes even further, replacing spinlocks with priority inheriting mutexes, so you now can preempt code that would not be preemptible with VP.

In practice VP gives better latency right now by about half. But as another poster pointed out this is probably due to debugging overhead and probably a few bugs, the VP approach has reached the limit while this is capable of improving worst case response times by a few more orders of magnitude. This is a great development.

Re:Compare this to Ingo Molnar's 'Voluntary Preemp (1)

Theovon (109752) | about 10 years ago | (#10482617)

Thank you very much for your informative explanation.

Does OSX have this latency because of its semi-microkernel nature? Otherwise, what is it about OSX that makes it have relatively low latency?

Given this new development, do you think Ingo will change tactics and adopt the new approach into what he is doing? Or are there any reasons why he shouldn't?

Re:Compare this to Ingo Molnar's 'Voluntary Preemp (3, Informative)

B1gP4P4Smurf (790700) | about 10 years ago | (#10482780)

Does OSX have this latency because of its semi-microkernel nature? Otherwise, what is it about OSX that makes it have relatively low latency?

From reading the I/O Kit docs (the driver writers guide for OSX, google for it) it looks like OSX does it the same way as Linux with Ingo's patches, they have a preemptible kernel and a realtime scheduling class for multimedia apps, and IRQs appear to be threaded, though the exact mechanism is unclear. The Mach ancestry helps in other areas, Mach ports on OSX are allegedly are a faster IPC mechanism than even Linux FIFOs.

MOD PARENT UP! (1)

gokeln (601584) | about 10 years ago | (#10482623)

Excellent commentary. Unfortunately, blocked by /. indentation scheme...

Re:MOD PARENT UP! (1)

B1gP4P4Smurf (790700) | about 10 years ago | (#10483236)

Not sure what you mean, it all looks fine on my machine.

Coming soon: SCO vs. Montavista (1)

peloy (26438) | about 10 years ago | (#10482483)

And of course, Montavista stole all this code from SCO since there is no other way Linux could have gotten real time capabilities that were already present in System V Unix. SCO to sue Montavista, film at eleven.

they can dream (1, Insightful)

quelrods (521005) | about 10 years ago | (#10482499)

Linux is a monolithic kernel. To be an rtos you usually start with a microkernel: Qnx, VxWorks, Hurd. In order to turn linux into an rtos they would have to rework it from the ground up. In addition they would have to completely break backward compatability. A popular RTOS that can be consumed by the masses would be nice. It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliability, and tons more. All the patches appear to do is attempt to get linux to pre-emtively multitask correctly. This by no means will make linux a real time os.

Re:they can dream (0)

Anonymous Coward | about 10 years ago | (#10482534)

Linux already multitasks correctly (a hell of a lot better than certain other OSs I could mention).

This is about giving guaranteed response and timeslots to realtime projects. The other things you mention have nothing to do with RT.

Re:they can dream (4, Informative)

drinkypoo (153816) | about 10 years ago | (#10482552)

It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliability, and tons more.

The only one of those that is a requirement for calling linux a genuine realtime OS is the guaranteed scheduling. However, you can already replace the kernel in memory with another kernel, linux has security models in the kernel these days, the boot time is pretty much dependent only on hardware initialization... If linux can get the scheduling to something people are willing to call realtime, that's pretty much the only thing missing.

Re:they can dream (0)

Anonymous Coward | about 10 years ago | (#10483442)

you can already replace the kernel in memory with another kernel

I didn't know that. How?

Re:they can dream (3, Informative)

Anonymous Coward | about 10 years ago | (#10482770)

To be an rtos you usually start with a microkernel

No, you don't. In recent time that's been true, but that's generally because the big RTOSs are often used in by vendors who need five nines of availability as well. An air traffic management application not only has scheduling requirements, but it simply cannot crash either, and a microkernel is one design to help pursue that.

A microkernel is not required. In some senses old time sharing systems were RTOSs because they guarenteed whoever paid X amount of money got Y amount of processor, throughput, etc. Those certainly weren't microkernels.

I always worried that my filesystem may get starved by an aggresive real time process in an microkernel based RTOS, but in my experience that's never been an issue. I should look up some research on that one of these days.

A popular RTOS that can be consumed by the masses would be nice.

Define masses? For almost all definitions of that term QNX's desktop version (free as in beer) seems to fit the bill. For most others TRON (or is that Tron?) seems to be what you're after. Are there any "masses" that these two OS's don't meet?

It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliability

I think you're talking about a microkernel there, except for the guaranteed proc time. Everything else is one of the (debateable) advantages of the microkernel design.

All the patches appear to do is attempt to get linux to pre-emtively multitask correctly.

Actually, it's talking about kernel preemption, which isn't exactly pre-emptive multitasking in the usual sense of the term. When that audio demuxers says "give me the processor!" in an RTOS, then it gets the processor, even if it has to preempt the kernel.

At heart RT is a schduling thing, mainly the processor scheduler. As the RT concept has matured, there has been a desire from ISV to see RT style scheduling of disk accesses, of bandwidth allocation, yadda yadda. These aren't needed to be a RTOS strictly speaking, but they are needed to be competitive. There have existed patches to make Linux a true, hard, RT kernel for quite a while, or to have "soft" RT as well. So, Linux being (at least, being capable of being) a RTOS is in some senses old news.

Re:they can dream (2, Interesting)

AaronW (33736) | about 10 years ago | (#10483213)

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.

Sad news ... Stephen King, dead at 54 (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10482567)

I just heard some sad news on talk radio - Horror/Sci Fi writer Stephen King was found dead in his Maine home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an American icon.

RT is useful for data acquisition (1)

vijayiyer (728590) | about 10 years ago | (#10482662)

I have used Linux with the RTHAL patches for data acquisition at high data rates synchronized by an external clock. A specialized application, yes, but useful nevertheless. Having this functionality completely rolled into the kernel will be nice.

Real-time support for 2.6 (5, Informative)

jd (1658) | about 10 years ago | (#10482687)

I believe RTAI were the first to produce real-time support for 2.6. Last time I looked, there was some problem with using preempt with RTAI, and it didn't like module versioning. These may have been fixed by now, though.


Timesys were next. I used Timesys at the last place I worked - it's good, but it's also inconvenient. They only seem to provide pre-patched kernels, and there's quite a bit of support stuff that's not GPL.


RT-Linux uses a similar technique to RTAI, to achieve real-time. There is a questionable software patent on the precise technique they use, which is (in theory) to prevent non-FOSS companies from obstructing real-time Linux work. It's unclear as to whether the patent could be used by hostile companies as "proof" of the IP "dangers" of Linux and FOSS in general, but there's always that risk. The problem with minefields is that they don't care who steps in them.


For those using older kernels, and only requiring "soft" real-time, then the real-time scheduler patch on Sourceforge might be sufficient.


That brings me to my other point. "Real-time" is a gradation, not a binary state. True "hard" real-time is extremely difficult to achieve, as it must be impossible to block any kernel thread or any interrupt. Your clock device also needs to be stable. The more exacting your requirements, the less you can afford to have even the smallest amount of drift.


The 2.6 preempt work, from what I understand, covers the bulk of the kernel but is not absolute. In other words, some things are simply going to block, like it or not, and that in turn means that you cannot absolutely guarantee a process a controlled time-slice.


For most real-time stuff (eg: basic multimedia stuff, etc) you don't need anything like as fancy as "hard" real-time. You simply aren't going to notice if a DVD is skewed by a couple of milliseconds - or even a couple of seconds - over a playing time of maybe 1-3 hours.


For that kind of stuff, "soft" real-time is certainly adequate. It smoothes things out to the level any person is likely to care about, but doesn't go much further.


Now, if you're in charge of a nuclear reactor or are designing the fly-by-wire systems for a Mach 10 aircraft, then any blocking is probably going to be unacceptable. (On the other hand, if you're in charge of a system like that, what are you doing reading Slashdot? Hey, what's that blinking red light, over your left shoulder? Uh-oh...)


There are patches for Linux, which give it nanosecond granularity. I don't know of any real-time patches which can make use of this level of precision, but there may well be projects where you really do require accuracy at that level. (Again, though, DVD playing is probably not one of them.)


It's great to see RT-Linux enter the 2.6 series, but it really isn't the first. That should not detract from users, though, because (frankly) who cares? If you're an admin or a user, you're concerned with whether it works, and the RT-Linux folks certainly know what they're doing.


Linux is progressing nicely in many of the top areas of high-end computing. Clustering, real-time, pre-empt, journalling filesystems, high availability, distributed shared memory, LVM, gigabit and ten gigabit ethernet, network QoS, nanosecond precision, etc. On the other hand, M:N threads seem to be dead, OpenMP is restricted to commercial software for Linux and many of those areas which are, in some way, being developed are disjoint and don't always work well together.


In other words, there is (as always) room for improvement, but what there is is certainly extremely impressive. Linux is rapidly developing a solid reputation in the high-end markets, and deservedly so. I look forward to seeing what happens next.

Re: RT-Linux for my Athlon64 FX-55 (= 2.4GHz) (0)

Anonymous Coward | about 10 years ago | (#10483314)

/* periodically switch the context each 10 us */
#define HZ 100000
...
It's for build a missile that shoots to the target in 23.73 miliseconds exactly, with a precission-error of 0.18 milimeters.

open4free ©

you fai7 i7 (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10482840)

hot on the heels of at least.' Nobody I've never seen and tha2t the floor I'm sick of it. in ratio of 5 to or make loud noises lube. This can lead [slashdot.org],

So what is the verdict? (0)

Anonymous Coward | about 10 years ago | (#10482874)

Lots of background noise but nothing specific.

So if someone can sumarize:

Are there any benefits for the senior noob who can patch and compile the kernel with the RT features.

What is the latest verdict with preemption (and how would the RT patch play along with it)? To enable or disable... it was never settled.

http://kerneltrap.org/node/view/3966

http://kerneltrap.org/node/view/2702

Re:So what is the verdict? (4, Insightful)

0x0d0a (568518) | about 10 years ago | (#10483202)

Are there any benefits for the senior noob who can patch and compile the kernel with the RT features.

No. Real time functionality is not just "better latency". Real time stuff is generally significantly less efficient than traditional schedulers. It's useful for specialized work -- this is not "better desktop" or "better server" for anything approaching the typical Linux end user.

If you're doing control work with Linux, then you might be interested.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?