“Additional real-time technology will be incorporated into the mainline Linux kernel starting with version 2.6.18, TimeSys reports. The real-time support, which previously had to be installed as kernel patches, was developed in part by TimeSys senior open source developer Thomas Gleixner, the company says. Gleixner was the main author of Linux’s hrtimer (high-resolution timer) subsystem, and has been a major contributor to Ingo Molnar’s real-time preemption patch. The changelog for the 2.6.18 kernel reflects the addition of 136 patches authored by Gleixner, along with 143 from Molnar, who works for Red Hat.”
I wonder if anyone has looked at the benefits or otherwise of real-time kernels and scheduling (with possible enhanced basic system libraries) for common services – such as the provision of DNS, RADIUS or even SMTP.
Realise that real-time does not necessarily mean faster peformance or bigger throughput (often it can mean less throughput).
Possibly benfits may include lower variation query-response times. That is, more consistency in the times a server takes to process and respond to a request, such as a DNS request.
One obvious benefit of a more consistenc is easier capacity planning and more believable problem alerting.
I said above that real-time does not usually mean faster performace – but it could if the OS was made aware of higher priority tasks, such as those that you are interested in. I know that some OSes can apply different scheduling schemes to at the process level – OpenSolaris for example gives better results when running video playback software under the RT scheduling class.
Ideas, comments, our experience welcome…
“such as the provision of DNS, RADIUS or even SMTP.”
These services aren’t time-sensitive enough for RT to make a real difference.
Real-time network applications will not work unless you can assign real-time QoS to the communication channel. Most such applications do only require soft realtime anyway as they are fine with some buffers – hard realtime is for devices. It makes development of specific hardware faster, cheaper, more performant, especially outside of the mass consumer market. (You could even solder your own expansion hardware). – The most common advantage for a desktop user might be with the impossibility of buffer underruns in burning CDs or smooth playback of audio even under heavy load of the rest of the computer; play a modern shooter with doing CD backup in a background process.
Let’s say…… someone with an older computer who can’t afford to upgrade? There wouldn’t be a need to upgrade if you load something on there with decent performance.
Or even for those of us who have beefy workstations?
Real-time operating systems are NOT for the average user. RTOS are tipically slower, and serve their purpose only on a niche market. That said, I welcome our new real-time overlords.
2.6.18 is stable release and will not get any new features. It´s also to late for 2.6.19. So this will definitly not be in the mainline kernel until 2.6.20 at least.
Ingo is integrated his RT patchset at http://redhat.com/~mingo/realtime-preempt/ incrementally into the mainline kernel. So the report that 2.6.18 already has some of the RT patches is true.
I remember that big portion of realtime patches should go in 2.6.19. Some parts might be ready only for 2.6.20 but this is how things work with Linux. Linux and his “army” want to be sure that nothing is sarcificed with realtime support and won’t allow hacks, but only proper solution in. It will be a compile-time option as realtime support doesn’t scale well for high-end machines, but it should even be suitable enough for desktop machines. LWN had few interesting articles about real-time partches recently.
I guess this is only going to work on specialized hardware. In PCs, neither the CPU nor the peripheral hardware make *any* timing guarantees, so support for this in the software is pointless. For embedded devices this is of course different (but then again I wonder why one would use a general-purpose OS in an embedded device…)
Linux is a kernel that certainly operates in many embedded devices. It just happens that Red Hat or Novell (aka “general purpose OS”) use _a_ Linux kernel for their enterprise products. That’s all.
BTW: It shows how scalable the Linux kernel is: embedded device, general purpose OS, mainframe.
Edited 2006-10-16 10:48
Real-time is useful for audio work and you don’t have to have specialised hardware to notice it. Processing audio signal from musical instrument, recording it and playing some other tracks at the same time really benefits from RT. Maybe it’s not perfect and accurate real-time but I have used patched 2.6.15 (or 16, don’t remember right now) and the latency decrease is quite noticable.
One area where real-time kernels are needed is audio productions. Software like JACK I believe required these patches. Hopefully as these patches become mainline, audio production software in linux will become more accessible, gain more users, and in the long run, catch up to Windows and OSX.