Linux Kernel Goes Real-Time 156
Several readers wrote to alert us to the inclusion of real-time features in the mainline Linux kernel starting with version 2.6.18. (Linus Torvalds had announced 2.6.18 on September 19.) Basic real-time support is now mainline. This will ease the job of developers of embedded Linux applications, who for years have been maintaining real-time patch sets outside of the mainline kernel. The announcement was made by TimeSys Corp., a provider of developer services. Much of the work was done by Thomas Gleixner at TimeSys and Ingo Molnar at Red Hat.
What about media? (Score:4, Interesting)
What other benefits would the desktop see from this?
Re:What about media? (Score:3, Informative)
Re:What about media? (Score:3, Insightful)
Re:What about media? (Score:1)
Re:What about media? (Score:2)
Anyway, that was exactly my point.
The realtime process in a realtime UNIX kernel can help an audio application by being able to field interrupts in a deterministic fashion.
Furthermore, a fully preemptive kernel (ie, all the kernel data structures protected) with multiple processes being able to be in kernel context at the same time can bring even regular (non-realtime) computer tasks.
If you think Linux is zippy now, wait until they do the really hard work to make that kernel fully preemptive. The systems will REALLY fly then.
Re:What about media? (Score:4, Informative)
In a "classic" unix kernel, only one process is in kernel context at a time. That's because if you have more than one process in kernel context at once, there's a good chance that they'll step on each other.
Say that two processes were in kernel context at the same time, and one wanted to delete data from a data structure and the other wanted to read from it. If the process that wanted to read from the data structure got a pointer to it, and then before it could do anything with it, the process that wanted to delete it came in and did delete it, when the process that wanted to read from that pointer it just grabbed came back, it would fail, and probably cause a kernel panic.
If all the data structures in the kernel are protected by semaphores (and spin locks in case of interrupt routines), and all the paths through the code prevented deadlocks (that's one of the tricky parts), then multiple process could be in kernel context at the same time.
You'll get the speed up because in a classic UNIX system if a process in kernel context took a long time with what it was doing, it effectively locks out all the other processes that want to go into kernel context until it's complete. When you have everything set up so that multiple processes can be in kernel context at the same time, you move the contention from the entire kernel down to individual data structure manipulation, and the wait times are much lower.
I believe (and someone that's actually still reading this correct me if I'm wrong), they do have semaphoring of code within the Linux kernel right now, but it's over big parts of the code, rather than individual data structures. There is some benefit of doing that, but not nearly the benefit of doing those individual data structures.
It's tough, but worth it in the end. I think the hardest part of this will be the drivers, and making sure that they behave well in a system like that.
Performance overhead of the -rt patch-set (Score:5, Informative)
I can definitely say that unlike some other approaches, the -rt Linux kernel does not introduce a "big speed penalty".
Under normal desktop loads the overhead is very low. You can try it out yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from here: http://debian.tu-bs.de/project/tb10alj/osadl-knopp ix.iso [tu-bs.de].
From early on, one of our major goals with the -rt patchset (which includes the CONFIG_PREEMPT_RT kernel feature that makes the Linux kernel "completely preemptible") was to make the cost to non-RT tasks as small as possible.
One year ago, a competing real-time kernel project (RTAI/ipipe - which adds a real-time microkernel to 'above' Linux) has done a number of performance tests to compare PREEMPT_RT (which has a different, "integrated" real-time design that makes the Linux kernel itself hard-real-time capable) to the RTAI kernel and to the vanilla kernel - to figure out the kind of overhead various real-time kernel design approaches introduce.
(Please keep in mind that these tests were done by a "competing" project, with the goal to uncover the worst-case overhead of real-time kernels like PREEMPT_RT. So it included highly kernel-intensive workloads that run lmbench while the box is also flood-pinged, has heavy block-IO interrupt traffic, etc. It did not include "easy" workloads like mostly userspace processing, which would have shown no runtime overhead at all. Other than the choice of the "battle terrain" the tests were conducted in a completely fair manner, and the tests were conducted with review and feedback from me and other -rt developers.)
The results were:
(Smaller is better. The full test results can be found in this lkml posting [theaimsgroup.com].)
I.e. the overhead of PREEMPT_RT, for highly kernel-intensive lmbench workloads, was 4.0%. [this has been a year ago, we further reduced this overhead since then.] In fact, for some lmbench sub-benchmarks such as mmap() and fork(), PREEMPT_RT was faster.
(Note that the comparison of PREEMPT_RT vs. I-pipe/RTAI is apples to oranges in terms of design approach and feature-set: PREEMPT_RT is Linux extended with hard-realtime capabilities (i.e. normal Linux tasks get real-time capabilities and guarantees, so it's an "integrated" approach), while ipipe is a 'layered' design with a completely separate real-time-OS domain "ontop" of Linux - which special, isolated domain has to be programmed via special non-Linux APIs. The "integrated" real-time design approach that we took with -rt is alot more complex and it is alot harder to achieve.)
See more about the technology behind the -rt patchset [redhat.com] in Paul McKenney's article on LWN.net [lwn.net], and on Kernel.org's RT Wiki [kernel.org].
Re:Performance overhead of the -rt patch-set (Score:2, Informative)
Re:Performance overhead of the -rt patch-set (Score:2)
Thanks - i forgot about these follow-up numbers that show even lower overhead for PREEMPT_RT: 0% lmbench overhead when compared to the vanilla kernel.
As a summary, i'm not all that worried about the performance impact. It is real, it will hit certain workloads more than others, but it's alot less than what was feared.
I'd still advise a generic distro against enabling it unconditionally, but a more specialized one can enable it no problem. These are the preemption kernel config options offered by the -rt kernel:
The first 3 config options are upstream already, and - as Thomas' article points it out - much of the "foundation" of PREEMPT_RT is upstream already too: generic interrupt code, generic time of day subsystem, hrtimers subsystem, the lock validator, the generic spinlock code, priority inheritance enabled mutexes, robust and PI-futexes, etc. Roughly half of what used to be in -rt is in the 2.6.18/19 kernels already.
Generic distros that want to scale from small boxes to really large multi-CPU boxes should use "Server" or "Desktop" preemption. Desktop-oriented distros could use "Low-Latency Desktop" too. Carrier-grade and embedded ones could use "Real-Time" preemption.
Re:What about media? (Score:2)
Re:What about media? (Score:3, Interesting)
Re:What about media? (Score:2)
Well, the changes to the kernel to support some sort of usable realtime system have improved the responsiveness of the kernel greatly. Probably none of the programs on my desktop will ever need hard realtime. But boy, do I like it if my programs keep responsive under heavy I/O from other programs.
I do not believe you need kHz-MHz resolution for any desktop application for timing.
Well, to each his own. Like I said probably none of the programs I run will use realtime 'contracts' with the kernel. But I expect this change to be as import as using a "server grade" operating system on the desktop. Just like everybody likes stable computer programs (and OSes), they also like responsive programs. And OSes will need to support that too, and for this support they'll need to change, for the better.
Re:What about media? (Score:4, Informative)
Re:What about media? (Score:5, Interesting)
But desktop users, or at least me, don't care about doing things "fast". I care about things feeling fast. I care about latency. So, do these patches help the audio on my computer not skip when I move a window? I've tried the premptive kernel patches in the past with no noticeable difference. How are these patches similar, different, or complimentary to Ingo Molnar's (whose patches are mentioned in the article). Thanks.
Re:What about media? (Score:1)
As for your sound playback is skipping...
You can up the pci latency on your audio card.. (using setpci) but that wont solve everything.. for instance sound still has to load from the harddisk, so the latency for the controller has to be up too.
Something could be sharing an IRQ with your soundcard or something else that makes things clag up.. (For instance, a pci network card can interfere with onboard sound card plugged into a certain PCI slot)
Of course, your computer could just be too slow. and some chipsets just plain suck. (eg older VIA stuff, which I unfortunately is in the majority of my computers)
My soundblaster audigy card cacks out at 5ms, so I took it out tried a whole bunch of s/h crud from my soundcard box, and now use an old SB Vibra128 (CT4810) and get near zero latency for music recording. So I guess the type of soundcard can have an impact on stuff like that.. I found CMI soundchips to be the absolute crummiest in terms of latency (and have had plenty of skips with them in ordinary desktop machines)
Re:What about media? (Score:2)
Re:What about media? (Score:2)
But sooner or later, they'll have to. Multi-core/multi-processor single box systems will greatly benefit from it.
Re:What about media? (Score:1, Interesting)
Eventually my computer came back to me, but not after trying to kill the amarok collection scanner a few times.
As far as I can see, the problems are several - when amarok starts scanning it does something nasty to KDE and doesn't stop it until the scanning is finished. Secondly, when scanning an AAC file, it seems to loop reading the same data from disk forever. Thirdly when scanning files, the disk drives are somehow monopolised by the scanner, so it's impossible for anything else to read the disk in a timely manner. That causes processes to run slowly, and loadavg builds up (due to cron, incoming server connections, and stuff). When loadavg gets high it's possible to SSH in but it takes many minutes and anything which requires disk I/O appears to hang. When loadavg gets very high, sshd detects this and drops connections (or maybe it's tcp_wrappers doing it).
Applications should not be able to monopolise the computer to the extent that everything else just freezes. If it's a problem with the disk I/O I'd like to see what reconfiguration of the hardware will fix it - this is just two SATA drives on the inbuilt SATA adapter, in a RAID-1 array.
Re:What about media? (Score:2)
Re:What about media? (Score:2)
Re:What about media? (Score:2)
It could be argued that preventing this situation is analogous to solving the halting problem. I've never seen it couched in those terms, but I wouldn't argue with it if it was.
Re:What about media? (Score:2)
Re:What about media? (Score:1)
Re:What about media? (Score:2)
However, in my experience, under any normal circumstances (ie, machine produced in the last decade, not doing massive multitrack music composition and playback), you're vastly more likely to run into driver problems causing skips. Any non-prehistoric machine (500MHz+) should easily be able to playback an MP3 and not skip while moving windows, even without realtime audio.
Re:What about media? (Score:2)
Re:proaudio cards for proaudio work (Score:2)
I have an M-Audio Delta 66 for occasional recording but mostly just music playback. I've read about others having similar problems to mine. Seems like there may be some specific issues with this card. I haven't had time to look into it too much, so I just thought I'd throw this question out there. I know there are a million variables as other replies have hinted at...
Re:What about media? (Score:2)
Neither did I on my Pentium 90. To get audio skipping with audio, you either need to use low-latency processing, or have a ridiculously busy box. Realtime will help low-latency processing run more reliable, and can also help by giving selected tasks higher priority, which will solve both problems. (And yes, I know what realtime means, and no, I'm not speaking in general, I'm speaking of this specific set of patches to linux).
Re:What about media? (Score:2)
Re:What about media? (Score:5, Interesting)
Re:What about media? (Score:3, Interesting)
http://ccrma.stanford.edu/planetccrma/software/ [stanford.edu] has offered a real-time kernel for as long as the project has been around, for the above reasons - and if you're trying to record 8 tracks of audio at 24b/96kHz you'll quickly realize that the kernel has to be able to handle all of that data precisely, or your drum kit recording is going to sound awful.
Re:What about media? (Score:2)
Re:What about media? (Score:2)
If you're really interested, I have some spectrograms of what OGG and MP3 do to a waveform. The data rate is undoubtedly important, but you also have to take into consideration the sample rate (which controls how many samples per second the decoder has to interpolate a waveform and side effects thereof) and the number of quantization bits available, which controls the resolution of the individual samples. Plus, MP3 has a lowpass filter which is somewhere between 16kHz and 19kHz, which for certain musical passages is really noticeable, though not so much so for just voice.
AFAIK, MP3 is by nature always a lossy codec, with no option for lossless encoding. If that's true, no matter how much information you want to make available to the encoder, you'll never be able to match the original waveform.
Re:What about media? (Score:2, Interesting)
Re:What about media? (Score:2, Insightful)
I know what you mean, and IMO many times sensory limitations are generalized to the entire population while extraordinary indviduals who spend time training their senses will be able to exceed them. I had the benefit of learning from professionals in audio production in a collegiate setting. The ~30ms rule was one I heard from many of my instructors and verified for myself a number of times (on analog and digital gear in state of the industry studios). Since I graduated 9 years ago I have been actively training my ears, I have also been a multi-instrumentalist for nearly twenty years. So take from that what you will.
I bet most people can't hear the difference between DVD quality and CD quality, and most of the consumer gear doesn't help there... I guess it's splitting hairs, but audio professionals who truly respect their craft will always strive to present the musicians' intent in the most transparent manner possible. I've always thought that breaking rules didn't mean much until I knew what they were.
Re:What about media? (Score:2)
Re:What about media? (Score:3, Interesting)
I for one believe that it could be immensely useful for Linux to provide the option of switching to a real time scheduler when starting a video playing - and for it to be able to tell you that there is no chance it will be able to run certain videos (HD for example) on older hardware.
Re:What about media? (Score:2)
Re:What about media? (Score:2)
There are media-tailored Linux distributions - StudioToGo [ferventsoftware.com] and 64Studio [64studio.com]. Also there are things like PlanetCCRMA, AudioSlack and the Gentoo Pro-Audio overlay that can tailor a vanilla distribution to the needs of an audio workstation.
Re:What about media? (Score:5, Informative)
And actually the grand parent is right to wonder about whether or not this will allow for a more responsive feeling system, because in general, it will. Much more so than the pre-emptive kernel routines already in = 2.6.17.*. If you've ever used a real time OS you'll know what I mean -- nothing feels so nice to use. The processor can be pegged, and have a ridiculous load average of say... 100 or something (100 tasks are trying to use 100% of the CPU), and you won't really notice any sluggishness... but, of course, tasks will just take a long time to complete.
It's not without it's downfalls though. Obviously being able to guarantee low latency interrupt responses is going to require some overhead. You'll definitely slow your computer down by using a real time OS, although unless you're a gamer you might not even notice.
All that said and done, unless you're using your computer for some very specific things like embedded devices, critical applications (medical, power station management, etc), and audio / video stuff, you'll probably never notice the difference.
I know a lot of audio people are happy about the real time patches because the delay between turning a dial, or moving the mouse, and the noises that come out of the speakers is quite noticeable even with really small delays.
Re:What about media? (Score:3, Interesting)
Real-time is all this and more.
Getting tasks to complete on time is actually not something that an operating system can guarantee: you can simply lie about how long your job will take. (But, like your compiler, if you lie to your operating system, it will get its revenge.) Or you can design your hardware so that it swamps the system with so many interrupts that it can't service any user tasks. This kind of problem is a property of the system as a whole, and the best that the kernel can do is guarantee that if you play by the rules, it will too.
Latency (be it interrupt delivery, signal delivery, context switch or whatever) is something that the kernel can guarantee for the most part, but even then, in an OS like Linux, where hardware drivers are part of the kernel, you also rely on those drivers to play nice. This means, for example, that it must not disable interrupt delivery around a loop.
The other main things you need are things like the ability to fix data in memory (which Linux has had for a while), fixed-priority tasks and the ability for a task not to be preempted by a task of the same priority.
For Audio Work! (Score:2, Informative)
Re:What about media? (Score:5, Informative)
Desktops and most servers do not get any benefit from a RTOS. RT makes it so that the system purposefully downgrades less-useful things like user input for maximum priority things like, say, polling a fetal heart monitor every n milliseconds or responding to an automobile collision to deploy an airbag.
RTOS in Linux is primarily useful for Linux-based routers. However, seeing that QNX has been in the industry for 25 years, has an extremely good reputation (it's the de facto standard in the auto industry), and is already POSIX compliant, Linux still has a long way to go. The price for QNX might be USD $10,000+, but if you actually have a need for a RTOS, licensing cost is not a major obstacle.
Re:What about media? (Score:2)
Re:What about media? (Score:2)
If a normal OS would *really* benefit from RT operations, don't you think that Linux, AIX, or Windows wouldn't have already implemented it? RT processing is only necessary in very specific applications. Almost all of them are for industrial equipment, safety equipment, and medical equipment where a few milliseconds of real time is actually important. A normal OS is concerned with *how quickly* something will occur. A RTOS is concerned only with *when* something will occur. It sacrifices performance for predictability.
Re:What about media? (Score:2)
Re:What about media? (Score:4, Interesting)
Yes - media is realtime (Score:1)
Contrary to the reply above, the answer is yes - multimedia is one application of a usage of real time signals (a timer signal). Basically, what it boils down to is the POSIX.4 standard. In MS Windows, the multimedia timers an alternative example (I believe). On most hardware, a clock resolution of about 970us is available. So you can get scheduling with an average error of half this (so your error is half a millisecond on average).
Real time has several aspects besides just scheduling:
-real time signaling queues (e.g. timers and other interprocess signals) and other inter-process communications
-the ability to lock pages into memory
-the ability to set real time priority (pri 33-43) above the kernel (20-32) and users (0-19). To say that another way - a real time process is the king of the system.
-the ability to choose a kernel scheduling method (e.g. FIFO, round robin)
-the granularity with which the kernel can be interrupted
-the latency in switching tasks
Real time has been traditionally a concern in control system applications where predictable scheduling is important or response to a hardware interrupt must be rapid. Multimedia and many gaming applications also fit this requirement.
Real time is undermined where things like underlying hardware can disrupt predictable execution (e.g. I've seen this caused by some file system drivers). Ideally, real time applications must be designed to assume they are in complete control of the system and should not rely on the timing of any I/O activity during their execution. A real time process must sleep for anything else on the system to run. Bugs in real time applications can be very subtle to detect and may occur at low frequency.
Adding full real time support for Linux is pretty important for both usefulness and credibility.
I believe so. At least, Stanford thinks so. (Score:2)
So can anyone tell me if these new features would be useful for improving the responsiveness of media applications in Linux?
Well, Stanford University's Media Lab offers the Planet CCRMA Linux distro (based on Fedora Core). One of its features has been custom kernels (two "speeds," even) compiled with Mr. Molnar's real-time patch (which I think is much the same as what is being discussed in this article). Planet CCRMA terms it a "low latency" fix and it's important in certain types of audio production where you want to record a "live" track in sync with a track that's already been laid down. Too much lag in the system (just a few milliseconds) can make the whole deal unworkable when trying to do "sound with sound" recording (musicians do this a bunch). I can tell you from personal experience that Audacity's usefulness goes down a couple of notches without it. :)
You can read more about the patched kernel here, down the page:
http://ccrma.stanford.edu/planetccrma/software/ins talltwosix.html [stanford.edu]
Hopefully, this will mean that the Media Lab folks at Stanford won't have to bother to maintain the custom kernels in the near future.
* * * * *
Although golf was originally restricted to wealthy, overweight Protestants, today it's open to anybody who owns hideous clothing.
--Dave Barry
This has got to be a good thing! (Score:1, Interesting)
Re:This has got to be a good thing! (Score:2)
BTW, it's a fallacy that "embedded" implies "tiny". Sure, a heart pacemaker is an embedded device, but so is a digital set-top box and so is an MRI scanner. Many modern embedded devices have demand for quite a bit of computing power.
Yes, but what does it do? (Score:1)
Re:Yes, but what does it do? (Score:2)
Make them an official part of the kernel.
I'd ask if you RTFA, but of course it's pointless.
lets try this again... (Score:2)
The article does not say what hrtimer and the real-time preemption patch actually do, nor does it say that those are the patches that were added to the kernel, merely that Gleixner worked on those as well as whatever those 136 patches are that made it into the kernel. So, what actually changed? Were internal APIs rearranged? Were long-held spinlocks replaced with shorter-duration spinlocks? Can the kernel preempt things it couldn't preempt before? Does the kernel export any new APIs to user space? What sort of improvements can we expect with these patches?
The article was quite vague in its technical details, so I was hoping someone could fill them in.
Re:lets try this again... (Score:2)
We, those who surf the web, play music, write email, host web servers and run databases will see no improvments.
Those who control tiny systems with ARM and MIPS CPUs will find life more consistent, because now there is The Official Real-Time Kernel, instead of a variety of non-similar patch schemes.
Not entirely correct. (Score:4, Informative)
For servers, real-time guarantees each process (or each thread, depending on implementation) a deterministic amount of time, so guarantees that denial-of-service to those who are currently having queries processed is impossible. (You are guaranteed your time on the server, no matter what.) However, because execution time is bounded, it also guarantees that response time can never be below some pre-defined threshold, either. A lightly-loaded machine will provide precisely the same response times as a heavily-loaded one.
For most servers, this is a pretty useless thing to guarantee - well, unless you're about to be Slashdotted. There are some exceptions. A server providing financial information would not really need to be able to respond faster off-peak, but must not fall over under stress. A networked storage device can't afford massive fluctuations in access time if it is to be efficient - mechanical devices don't have a zero seek-time. The better the device can guarantee an operation will take place at a specific time, the better the device can order events to make use of what time it has. Network routers that are hard real-time should never fail or deteriorate as a result of network congestion, it should merely hit the limit of what it can handle and not allocate resources beyond that point. (A router or switch that is not real-time will actually deliver fewer packets, once it starts getting congested, and can fail completely at any point after that.)
Real-time is not going to be generally useful to the majority of individuals the majority of the time, although it will be useful to most individuals some of the time (eg: multimedia), and to some individuals a great deal of the time (eg: those setting up corporate-level carrier-grade VoIP servers, unmanned computer-controlled vehicles, DoS-proof information systems, maglev trains, etc). All classes of user will have some use for real-time. Even batch-processing needs some degree of real-time - jobs have a well-defined start-time and must never be given so much time that the next cycle of the same job is incapable of starting on time. It's not "hard" real-time, but it's still real-time in that it is still a very well-defined set of bounds on when a process is executed and how much time it gets.
"No improvements" is therefore entirely incorrect. No noticeable improvements - maybe, depends on the situation. Some situations will improve significantly, others may actually deteriorate. No overall, on-average improvement would be closer to the truth. As for tiny systems - I run Fedora Core in full desktop mode on a MIPS, RiscOS was designed for the ARM, and I've seen plenty of embedded systems that need real-time on Opterons. For that matter, VxWorks - the "classic" hard real-time OS - is designed around the Motorola 68040 architecture and is often used by military and science labs to handle bloody huge applications (think of something of comparable size and complexity to Windows Vista as it was going to be before all the interesting bits got chopped out).
Also, when you think of "tiny systems", you generally picture something the size of a matchbox that can be powered by a watch battery. In practice, data collection systems (a heavy use of real-time) will usually use VME crates that might easily have 16 CPUs, 128-bit instrumentation busses, a few tens of gigabytes of RAM, a fan that sounds like it was pulled out of a jet fighter, and power requirements that would seriously strain a domestic power grid. The last time I saw a truly small real-time system was at a micromouse tournament, although undoubtedly there are people who use them on tiny systems. The biggest money and the heaviest demands are to be found in areas needing much bigger iron.
Re:Not entirely correct. (Score:2)
For example, we could have an API that guarantees a video player realtime scheduling and all that goes with it, as long as it uses less than eg. 50% of the CPU (to prevent lockup). If the apps are then properly written (impossible for video, right now, because of the X server), then it won't be a matter of fewer skips as it is of no skips ever, under any circumstances. This is as it should be - modern computers are plenty powerful enough to give a good audio/video experience.
Real-time OS (Score:3, Informative)
http://en.wikipedia.org/wiki/Real-time_operating_
"A real-time operating system (RTOS) is a class of operating system intended for real-time applications. Examples include embedded applications (programmable thermostats, household appliance controllers, mobile telephones), industrial robots, industrial control (see SCADA), and scientific research equipment.
A RTOS is valued more for how quickly and/or predictably it can respond to a particular event than for the given amount of work it can perform over time. Key factors in an RTOS are therefore minimal interrupt and thread switching latency."
Re:Real-time OS (Score:1)
I'm pretty sure most anyone reading this article on Slashdot knows what an RTOS is.
The remaining few know where wikipedia is
Re:Real-time OS (Score:1)
Re:Real-time OS (Score:3, Insightful)
Re:Real-time OS (Score:2)
Re:Real-time OS (Score:2)
Anyone with experience on unix-like RTOSes is probably glad to see RT being introduced into the main branch, as the responsiveness of a RTOS is, by far, much more satisfying. The O(1) scheduler was a nice step forward. The incoming Linux RTOS-like additions, such as preemptible kernel, priority inversion avoidment (not sure if this has been included), etc. will use few more CPU cycles and a bit less disk and I/O throughput, but will boost the user experience. This second step for introducing RT characteristics will not imply Linux becoming Hard RTOS, just a Soft RTOS. In few words: there will few changes related mainly to kernel preemption, in line with TimeSys and BlueCat Linux (i.e. adapting the RT patching to the main branch). I hope that Hard RTOS support will be added in a far future, as it involves driver architecture rewriting (the 2.4 to 2.6 it is trivial in comparison). IMO, it's worth the effort (LynxOS Posix Desktop anyone?
Video playback (Score:1, Offtopic)
Re:Video playback (Score:1)
Because video drivers are shit. (Score:1)
So it's not linux itself, it's getting good drivers and making sure you use them.
Re:Video playback (Score:1)
With properly accelerated video playback you will have no problem. For example "Xv" playback on newer Ati cards uses hardware acceleration. Also, have a look at the XGL demonstration videos where they play videos overlapping, transparent, in the root window and deformed all at once.
Re:Video playback (Score:2)
Re:Video playback (Score:2)
I doubt it's related to the stylus issue, although it's been a long time since I looked at that kind of thing.
Anyways, post your system details (cpu and speed, graphics card, linux distro, etc) and I'll see if I can write something more meaningful.
Re:Video playback (Score:2)
I really couldn't begin to guess about the tablet issue. If your code-fu is strong, I'd start by searching for the differences between what GIMP does and what everything else does. Might be something about GTK mouse handling that's different to other things. I realise that's not a realistic answer for most people though (either time or skills or both)... Good luck
Linux audio software will now be #1 (Score:2, Informative)
Re:Linux audio software will now be #1 (Score:1)
Wishful thinking, my friend.
Re:Linux audio software will now be #1 (Score:2)
"The Ardour project is happy to be able to announce the involvement and support of Solid State Logic (SSL), one of the most respected and trusted names in the field of audio technology. SSL has chosen to support Ardour's development and to promote the idea of its broader adoption within the audio technology industry."
Solid State Logic [solid-state-logic.com]
Harrison/GLW [ardour.org]
Re:Linux audio software will now be #1 (Score:2)
It's safe to say Apple isn't worried about losing ANY market share in the content creation industry.
Re:Linux audio software will now be #1 (Score:2)
Pro Tools has been the main tool for audio professionals for decades. Sounds like a good choice if you want to clone something. I'm sorry you can't get everything you want, but even though it's third-rate, at least it's improving. And it's not like it's the only thing out there for linux either.
Ardour supports LADSPA plugins. It doesn't support AU because that's mac only. It doesn't support VST because that's windows only. It doesn't support RTAS because it's not an open standard, and requires special hardware. It may work with VST through wine, and if a windows or mac version is ever made, it will most likely support native plugins there.
JACK is not a format. Jack is to linux what ReWire is to windows. Since jack can be used to route audio between applications, it can also be used to route audio between your soundcard and your applications. In general this gives you more flexibility. If you don't want to know this, I can write you a 2-line script so you don't need to be aware of jack. However, it will still be there, giving you more flexibility than you ever had on windows, without any loss of performance. Just because it's different from what you're used to, doesn't mean it sucks. The only thing that sucks about jack is that it doesn't do MIDI!
Well, if you can only be satisfied by having exactly the same applications as under windows, you know where to find them. I will not dispute that linux could need more audio applications, but we don't need clones of all the above. ProTools, Logic, and Ableton Live all more or less perform the same function. They allow you to play, record, and arrange audio and midi tracks. Final cut adds video tracks. Reason has a nice selection of synths and effects. What we need under linux is tools to do the above tasks: play, record and arrange midi, audio and video tracks; create audio; modify audio and/or video. Tools should focus on those tasks, not in whether it duplicates the function of Logic or Ableton Live.
That kind of "pro" also has near unlimited funds and can afford to fill their studio with hard- and software for millions of dollars. Surely they can afford someone to help them inserting an ubuntu disk. As a non-pro, and from experience, I know that windows consumes a lot more of my time than linux ever has. An ubuntu install just works, compared to windows that must be tweaked for days before it works well, and must be reinstalled every 6 months. As a hobbyist musician, and tinkerer, I'd be much more interested in a home-studio running linux, than one with windows. You'd be surprised how many computer musicians agree with me.
They should. Everything seems to be going windows!
Re:Linux audio software will now be #1 (Score:1, Informative)
Re:Linux audio software will now be #1 (Score:2)
Re:Linux audio software will now be #1 (Score:2)
I'm sure ardour doesn't try to be a third-rate ProTools clone.
The hardware support isn't needed anymore. Fast multicore processors have pretty much replaced the need for specialized hardware. Of course, dedicated DSP hardware is still better, but it's certainly not the future anymore. Besides ProTools hardware is expensive, and I doubt you can get specifications for it. Besides, it's not obvious what other kinds of hardware you can use. On the other hand, software audio plugins, and support for multichannel low-latency sound-cards is there.
And if you go to a professional office in L.A, you won't see Blue Gene, you will see a DELL. And you won't see "La Modernista Diamonds" by Caran d'Ache, but a BIC-pen. Does that tell you that you something? Perhaps that proof by reference to "the pros" doesn't work?
Re:Linux audio software will now be #1 (Score:2)
Second, let me know when Ardour supports things like VST, AU, RTAS, Rewire, and doesn't run on Linux and that goofy JACK audio format. Also let me know when it upgrades its interface out of 1990s-era Pro Tools, since the interface is a direct rip-off, and let me know when it stops being slower than the Windows and Mac alternatives. Let me know when it interfaces with front-ends like Logic or Ableton (oh, right, Linux doesn't have them). And let me know when you can get professional technical support without resorting to IRC channels and sparse mailing list archives.
I could go on and on and on here...
Re:Linux audio software will now be #1 (Score:2)
What does this really mean? (Score:3, Insightful)
Anyone know if this is just the ADEOS micro-kernel patch being distributed as part of the vanilla kernel? If not, is it compatible with RTAI, Xenomai, Fusion, and RTLinux?
Re:What does this really mean? (Score:2)
Re:What does this really mean? (Score:2)
1. futexes (locking for app code) with priority inheritance
2. high-resolution timers
It's progress, but not everything you need yet (Score:4, Interesting)
Linux has made major progress in the real-time area. But it still doesn't have everything needed.
Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.
The Linux CPU dispatcher is now more real time oriented. (Finally!)
Interprocess communication in Linux is still kind of lame by real-time OS standards. The tight interaction between CPU dispatching and messaging still isn't there, although it's getting better. Interestingly, it's there in Minix 3, and of course, that's been in QNX for years. For simple real-time apps, though, this may not be an issue. Generally, though, if you find the need to use shared memory between processes, it's because your OS's messaging lacks something.
While Linux has been getting down to millisecond level response, QNX has been moving towards microsecond level response. The goal moves. However, millisecond response is good enough for most applications. What really matters in real-time, though, is worst-case response, not average. Benchmarks for real time OSs put a load on the system and measure how fast it responds to a few million interrupt requests. The number people look at is the longest response time.
Despite this, Linux is probably now good enough for most real-time applications that can tolerate a big kernel.
Re:It's progress, but not everything you need yet (Score:1)
OpenBSD speciality is security. I wonder if every single *NIX have then their own specific niche.
Linux aims to be generic, Jack of all trades and then master of none?
I don't know you tell me. Maybe Linux wins in portability, openess, ease? popularity? It's nice to see it evolving.
Re:It's progress, but not everything you need yet (Score:5, Informative)
Linux has made major progress in the real-time area. But it still doesn't have everything needed.
Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.
That's where my -rt patchset (discussed by Thomas in the article), and in particular the CONFIG_PREEMPT_RT kernel feature helps: it makes all such "interrupt lockout" driver code fully preemptible. Fully, totally, completely, 100% preemptible by a higher-priority task. No compromises.
For example: the IDE driver becomes preemptible in its totality. The -rt kernel can (and does) preempt an interrupt handler that is right in the middle of issuing a complex series of IO commands to the IDE chipset, and which under the vanilla kernel would result in an "interrupt lockout" for several hundreds of microseconds (or even for milliseconds).
Another example: the -rt kernel will preempt the keyboard driver right in the middle of sending a set of IO commands to the keyboard controller - at an arbitrary instruction boundary - instead of waiting for the critical section to finish. The kernel will also preempt any network driver (and the TCP/IP stack itself, including softirqs and system-calls), any SCSI or USB driver - no matter how long of an "interrupt lockout" section the vanilla kernel uses.
Is this hard technologically? Yes, it was very hard to pull this off on a general purpose OS like Linux (the -rt kernel still boots a large distro like Fedora without the user noticing anything) - it's the most complex kernel feature i ever worked on. I think the diffstat of patch-2.6.18-rt5 speaks for itself:
How did we achieve it?
The short answer: it's done via dozens of new kernel features which are integrated into the ~1.4MB -rt patchset [redhat.com] :-)
A longer technical answer can be found in Paul McKenney's excellent article on LWN.net [lwn.net].
An even longer answer can be found on Kernel.org's RT Wiki [kernel.org], which is a Wiki created around the -rt patchset.
Re:It's progress, but not everything you need yet (Score:2)
It's painful reading how that works. It's an achievement. "613 files changed." "It's the most complex kernel feature i ever worked on." But it's one of those things that, for legacy reasons, is much more complex and ugly than it should have been.
It's sad how much effort today goes into working around bad early design decisions. After writing drivers for QNX, where drivers are just user programs with a few extra privileges, it's painful to see the contortions people go through to do them in the more primitive operating systems. The basic problem is that the original UNIX driver model was a "top part", called from read and write calls, and a "bottom part", called from interrupt level. Today, Linux drivers tend to have some threads of their own, they're loadable, and the locking primitives are better, but the headaches of the legacy architecture remain.
The price of this is that drivers remain the biggest source of OS failure. OS developers pile hack on top of hack to try to fix this, the kernel gets bigger and bigger, and it still isn't airtight. Xen and Minix3 are starting to get it right. Drivers, even hardware drivers, are user programs in those operating systems.
I know, it's not going to get fixed for another generation. QNX is going nowhere because the company that now owns it is in the car stereo business. Minix 3 is still a toy. The Hurd people totally blew it. Mach gave microkernels a bad name. But this actually can be done right, and it takes less code to do it right than the mountain of patches needed to do it the hard way.
complexity of the -rt patchset (Score:3, Informative)
It's painful reading how that works. It's an achievement. "613 files changed." "It's the most complex kernel feature i ever worked on." But it's one of those things that, for legacy reasons, is much more complex and ugly than it should have been.
I think you misunderstood my point. The reason why our patchset is so complex and so large is because we want to do it right. The quick-and-ugly shortcut is alot smaller (and it has been done before), and it brings problems similar to the ones you outlined - but that's not the path we chose.
Here is an (incomplete) list of kernel features/enhancements split out of -rt and merged upstream so far:
Note that all those features originated from the -rt effort, but they have justification and use independent of real-time considerations. In other words: they make sense in a general purpose OS anyway. And better yet: our current judgement is that much of the rest is in this category too. So what we did and what we are doing are dozens of seemingly unrelated enhancements to the Linux kernel, which in the end enable hard real-time.
Is such an approach more complex instead of a quick-and-dirty hard-realtime kernel feature? Sure it is - but in my opinion this is the only way it can stay maintainable in the long run. And as a happy side-effect we'll get a hard-real-time capable kernel that will run on virtually every piece of hardware on this planet. And since we've got all the time we need and no deadlines to meet, it can and will be done =B-)
Re:It's progress, but not everything you need yet (Score:2)
I can't guarantee I can pull it off, but I'm putting a hell of a lot of time into it, and I want the results really badly. Hopefully you'll hear from me in a year or two with an exciting announcement.
Speaking of the IDE driver... (Score:2)
Did you ever get it fixed? If so, how?
(Disclaimer: I work with Linux in embedded multimedia players) One of the real problems I've had wrt to the IDE driver was that it would occasionally hold interrupts for 130 milliseconds! When you're playing video at 30 fps, 130 milliseconds is several frames. It creates a very difficult situation to work around.
I found a solution, but given the time pressure, was never able to formally verify it. I am kind of curious as to what you did, and if it was similar to my approach.
Bad for windows embedded (Score:3, Interesting)
I was at the MEDC 2006 [medc2006.com] and one of the presentations was about how Linux was comparing to Windows Embedded.
We got bunch of benchmarks showing how much more consistent the kernel response time were from Windows CE (custom Kernel) versus the Linux kernel, and how -on average- the Windows kernel had shorter response time. Some people in the audience asked (more than once) if they had benchmark from the Linux kernel with the real-time patches applied ... and the answer was they were benchmarking a 'for desktop' Linux kernel versus a 'for real-time' Windows Kernel. I was expecting M$ to put biased numbers but I could not stand it and left the room after 10 minutes.
So the great thing about this announcement is that next year they won't be able to pull this off. Honestly I would not be surprised to see them use a 2.4 kernel, or show us how the stock Desktop kernel with a crap-load of unnecessary modules take so much more resources than the optimized Windows kernel.
(sorry to post Anonymously, I guess I'm a Coward)Re:Bad for windows embedded (Score:1)
Hello (Score:2)
Re:Open source at it's finest (Score:4, Informative)
Do you even know what Real-Time computing means? Do you know what an interrupt is? Can you name even a single one RT OS ?
sigh... from wikipedia: http://en.wikipedia.org/wiki/Real-time Computing [wikipedia.org]
Well, the meaning has changed somewhat (Score:5, Informative)
Typically, it is indeed used in simulations, but very rarely on a 1:1 simulated-time-to-wall-clock-time basis. Simulating the formation of a solar system, or the results of runaway nuclear fission cannot be done on a 1:1 basis. Instead, real-time's guarantees permit you to firmly quantify a constant ratio between wall-clock time and simulated time - provided the programmer can firmly guarantee that a given simulated time interval will never require more than a certain amount of wall-clock time to simulate and a barrier can always be established to prevent more than the desired amount from being simulated. This rules out all event-driven simulations, herustics, variable N-body problems, fixed-precision variable-mesh CFDs, etc.
As soon as the number of variables or steps becomes indeterminate for a given simulated unit of time, you cannot pre-determine the wall-clock time needed to simulate it. If, however, the guarantees are enforced, it is STILL real-time in the accepted sense, even though you have no idea prior to running the program as to when a simulated unit of time will occur. An OS does not stop being real-time if it is fed a non-computable problem, it merely stops being able to tell you when it'll get done.
ADEOS - the microkernel used in RTAI - is "hard real-time", as is VxWorks. TimeSys' Linux patches are soft real-time. Soft real-time is good for audio/video, but is pretty naff when it comes to providing any guarantees. It's usually faster than hard real-time, as it can spend more time processing than synchronizing, so is more useful on a desktop system. With suitable patches (nanosecond timers, real-time clock chip drivers, etc), Linux can be a damn good hard real-time system, but there are performance penalties. Besides, broadcast-quality images are 30 fps in the US and 25 fps in the UK. Being able to align a frame on a nanosecond boundary is thus a complete waste of time. It's damn useful if you're running a particle accelerator ring or even a maglev train (350 mph requires absolute sub-microsecond guarantees on timings), but not many home users have these yet. A pity - it might be fun to have a synchotron source.
Does Linux need hard real-time, then? Oh, certainly. It's popular in the very groups of people who are interested in nuclear science, mass transit or quantum cosmology. I firmly believe that patches that provide such mechanisms are not merely useful but extremely desirable. Bleeding-edge needs drive technology precisely because that is where technology isn't, so keeping in reach of those folk is vital.
Does Linux need real-time in the kernel? Certainly, though the soft real-time that has been added is probably sufficient. (I hate saying things like that. I'm a geek and I'm proud of it, and therefore want Linux to have the maximum flexibility possible. However, poorly maintained code is worse than no code at all, and there just isn't the userbase to keep hard real-time in the kernel at an acceptable standard.) As I said, soft real-time is all you need for multimedia. It's also all you need for games and other stuff that Linux hasn't been nearly hot enough in in the past.
Hard real-time distributions are another matter. For that matter, a distribution that provided a good set of hard real-time tools, clustering tools and CAM drivers would probably be very popular nor only with the scientific community but also with industry. A distro that pushed Linux into markets that couldn't be reached without effort from any mainstream project would undoubtedly be a good thing. It would be very much a minority effort, and yet would require far more sophisticated QA and technical support, so no sane person would attempt such a thing. Of course, I've never been accused of being sane...
Is the -rt patchset hard-real-time? (Score:3, Informative)
ADEOS - the microkernel used in RTAI - is "hard real-time", as is VxWorks. TimeSys' Linux patches are soft real-time.
Small correction: if by "TimeSys' Linux patches" you mean the -rt patchset [redhat.com] that i'm maintaining (and to which Thomas is a major contributor), and in particular if you mean the CONFIG_PREEMPT_RT kernel feature, then the answer is a clear "no": it's not "soft real-time", it's intended to be "hard real-time" in the same sense as ADEOS/RTAI is.
The -rt patch-set implements a fully preemptible Linux kernel, which allows a higher-prio event to preempt any lower-prio processing: it can preempt device driver interrupt processing or other "irqs off" critical sections or other normally non-preemptible (for example spin-locked) code within the kernel, immediately. (it does all the necessary hard-real-time things one would expect: it pushes interrupt processing into special kernel threads, it implements priority inheritance for all Linux locking primitives to guarantee processing and to get out of priority inversion scenarios, etc.)
See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net [lwn.net], and on Kernel.org's RT Wiki [kernel.org]. You can also try out an -rt kernel based Linux distribution yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from: here [tu-bs.de].
Hard-real-time in Linux? (Score:4, Informative)
I hate saying things like that. I'm a geek and I'm proud of it, and therefore want Linux to have the maximum flexibility possible. However, poorly maintained code is worse than no code at all, and there just isn't the userbase to keep hard real-time in the kernel at an acceptable standard.
We have good news for the geek in you: the upstream Linux kernel is already more than 50% on the way to become hard-realtime :-)
The 2.6.19-rc2 kernel already includes the following features/subsystems, which are the precondition of hard-realtime (PREEMPT_RT):
Most of these features were written for and prototyped in the -rt tree and were split out and merged individually. (they all have other uses besides serving a hard-real-time kernel, so their merging was largely uncontroversial)
Granted, there's still 1.4+ MB of patches pending in our 2.6.18 based -rt tree [redhat.com] (such as the core bits of PREEMPT_RT, irq threading, high-res timers, dynticks and more), but roughly the same amount of code has been merged upstream already, and we can now see the end of the tunnel.
In fact, i'd say that the most controversial ones are already merged and the flamewars are largely over: such as the generic mutex code (which replaced semaphores half a year ago in 2.6.16/17) or the priority inheritance and rt-mutex code (which is now in 2.6.18).
Re:Hard-real-time in Linux? (Score:2)
What I specifically want to know is what do you have left that's not in the mainline tree yet :) I can take the whole list and see what went in. Too bad my distro-of-choice won't have 2.6.18 this release; but the next release probably will be 2.6.19. I've been waiting for prio-inherit for a long, long time.. :)
What's this dynticks and high-res timers business? Is there documentation for these this time or does Redhat still go on a "write the code and some marketing" policy?
Ok, now answer me this. (Score:2)
Seriously, this is cool stuff - I was thinking we were only going to get the earlier soft real-time stuff that I was seeing from Timesys a few years back - which was pretty good, but was not of the RTAI ilk. I don't know what you spiked their water with to get hard real-time code, but it must've been damn good stuff.
glibc support? (Score:3, Interesting)
I have a question about the new mutex features: what glibc version is required to use this stuff? do I need other user space libraries?
The latest upstream glibc version (2.5) has it:
(See: http://sources.redhat.com/ml/libc-alpha/2006-09/ms g00065.html [redhat.com]
)
No other userspace library is needed.
Re:Open source at it's finest (Score:3, Informative)
I'm not sure any normal person will really care or notice the real-time stuff added to Linux. but I'm sure many companies are pleased that it has made the mainstream kernels. Usually we have to use funny extensions or patchsets.