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.

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.

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

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.