Kernel 2.6 Real-Time Benchmarks

An anonymous reader writes "This whitepaper at LinuxDevices.com includes benchmarks comparing the real-time performance of the vers. 2.4 and 2.6 linux kernels, based on LynuxWorks' BlueCat Linux 5.0 beta. The graphs compare the results for average and worst-case measurements of both interrupt response and task switch performance for the two kernels, running on a 1GHz Pentium III under relatively heavy load. Check it out -- there's an enormous improvement. The article also includes a rundown of other features of the new kernel that seem likely to be welcomed by embedded developers."

Comments

Wider Application?

[4of12]

I'm hoping the benefits of these performance improvements aren't limited to single-purpose embedded devices.

Better interactive response (framebuffer, keyboard, mouse) would help desktop users, while some of the enterprise warehouse folks could use less interruption of important I/O tasks.

Maybe those aims can be achieved somewhat by these kernel improvements.

it doesn't say

[Tirel]

which version they were using exactly.. test2-mm2? test3-ac1? test1? this is supposed to be a serious article?

What about the interactivity patches?

[dpilot]

The article (Yes, I RTFA.) talks about the responsivness of the new kernel, showing dramatic improvements in active and maximum latencies. Yet at the same time, there are people working very hard on a set of 'interactivity patches' and complaining of skipping when playing music on 2.6.

I haven't followed those discussions back to the beginning, so I don't know if they're gilding the lilly. But the intense work on interactive scheduling *now* scares me about like the late work on the VM did with the 2.4.0 release.

Just like the VM was the Achilles heel of 2.4 will interactive response, particularly playing music on a system under load, be the bane of 2.6?

Re:What about the interactivity patches?

[oever]

Playing music on a 2.6 kernel is certainly not perfect, especially in the first 30 seconds of a song with xmms. During this time xmms is probably loading the song and the disk access holds back the music stream.

Performance is, however, much better than with 2.4.

Re:What about the interactivity patches?

[StarBar]

Playing music on a 2.6 kernel is certainly not perfect, especially in the first 30 seconds of a song with xmms. During this time xmms is probably loading the song and the disk access holds back the music stream.

That only shows that xmms is not taking advantage of the new possibilities on the 2.6 kernel. It is up to the application to set priorities between tasks/threads, it is not something the kernel will do by itself. Properly set priorities will get you a much better sound experience on the 2.6 kernel. The preemptiveness of the 2.6 kernel will get rid of the lagging cursor movements, among other things, and that has nothing todo with priorities, so you will get it automatically. This might get you a feeling of better performance but infact it is just a better system response to your interaction. // Starbar

May I re-ask the question I asked on Monday?

[Anonymous Coward]

May I re-ask the question I asked on Monday? And maybe throw in one of my responses for good measure?

How does this compare with the kernel that was reviewed [and thoroughly trashed] by Dedicated Systems last August?

PDF DOCUMENT: http://www.qnx.com/products/ps_neutrino/benchmarks /elds/qnx62_elds.pdf

**********

NO - I'm not a QNX employee.

I am, however, about to embark on a huge project that involves real-time collection of massive amounts of biometric data, and I've spent the last several weeks investigating the state of the art of RTOS's.

We are looking at five possible candidates: VxWorks, Linux, CE.NET, QNX, and LabVIEW Realtime. VxWorks has a lot of market share, but the consensus seems to be that, under the hood, it's a little shaky. The consensus also seems to be that Linux just ain't ready for primetime; in fact, Linux realtime performance is so bad that people believe the kernel will need to be re-written from the ground up before it's ready to play in this league. Don't know much about LabVIEW Realtime, except that the National Instruments salesdroids are happy to sell it to you. QNX looks like it's got the nicest kernel of all, but it's not clear that it's got the driver & third party application support we might need.

Which leaves us with CE.NET: It's got surprisingly good performance [bests VxWorks in tests], it's got all the multimedia codecs of Windows, and it's got built in support for ActiveDirectory [so technicians could upload data directly into the database and sign their work right then and there].

On a purely performance-based evaluation, I'd probably choose QNX, but because of its flexibility, we'll probably go with CE.NET.

Anyway, back to my original point: How is this new 2.6.x "realtime" kernel any better than the 2.4.x "realtime" kernel that failed so miserably in the Dedicated Systems review?

Again, not trolling - just looking for all the information I can amass.

Thanks.

Beware TCQ on 2.6.0

[tzanger]

LKML verified it and I've experienced it personally -- TCQ on IBM Deathstar drives (mine were 60G, the LKML was 120G IIRC) can cause massive fs corruption.

Apparently a queue depth of 8 (the default it seems) is the specific culprit. LKML seems to say that TCQ of 32 works but I've turned it off entirely now.

It's marked experimental for a reason. :-)

Good Job, SCO!

[Anonymous Coward]

That is some very fine code.

Re:Linux 2.6 != operating system

[CentrX]

It schedules tasks, handles input/output with hardware, allocates storage and memory, manages processes... it's an operating system. Now, it may be more precise to say "Red Hat Linux" or "GNU/Linux", but that doesn't mean that Linux isn't an operating system.