Linux 3.0 Real-Time Kernel Released

[phoronix]

Phoronix: Linux 3.0 Real-Time Kernel Released

After not being updated for a few mainline kernel release cycles, the real-time (RT) Linux kernel has been updated against the Linux 3.0 kernel release...

http://www.phoronix.com/vr.php?view=OTcwMg

[not.sure]

How about some fresh rt vs vanilla benchmarks.

[NomadDemon]

jack + ardour should use it i guess

also interested

[Cyborg16]

How about some fresh rt vs vanilla benchmarks.

I don't think RT-linux is about benchmarks. See the FAQ:

What is real-time?
Real-time applications have operational deadlines between some triggering event and the application's response to that event. To meet these operational deadlines, programmers use real-time operating systems (RTOS) on which the maximum response time can be calculated or measured reliably for the given application and environment.
A typical RTOS uses priorities. The highest priority task wanting the CPU always gets the CPU within a fixed amount of time after the event waking the task has taken place. On such an RTOS the latency of a task only depends on the tasks running at equal or higher priorities, all other tasks can be ignored. On a normal OS (such as normal Linux) the latencies depend on everything running on the system, which of course makes it much harder to be convinced that the deadlines will be met every time on a reasonably complicated system. This is because preemption can be switched off for an unknown amount of time. The high priority task wanting to run can thus be delayed for an unknown amount of time by low priority tasks running with preemption switched off.

[not.sure]

I don't think RT-linux is about benchmarks. See the FAQ:

We know. But it would be interesting to see what kind of raw/throughput performance concessions (if any) one has to make when running RT.

Of course having an actual latency benchmark in PTS would be awesome, but we've talked about the difficulties with that many times...

[curaga]

Syscall latency can be measured, it's UI latency that can't really.

[del_diablo]

If its going to be benchmarked, you need to measure how stable the troughput is.
In games you tend to either measure arveages or ends(minimum and max).
What you need is 2 graphs, and perhaps 20 minuttes playtime on something with somewhat unstable FPS(if its a game).
A measurement on latency could also be done, via external equipment(highspeed camera?).

[kgonzales]

Might not be useful to benchmark...

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2.0/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html

Most of us do not run workloads that need RT. Audio is an interesting case in that it doesn't need low latency but it needs to eliminate the spikes in latency. Kernel tuning can do most of that, but RT makes it more certain.