|
|
|
tschak909
|
 |
« Reply #1 on: June 25, 2012, 04:29:12 pm » |
|
If you're asking these questions in such a general manner, I would suggest going back and understanding:
(1) what a real time kernel actually is,
(2) what parts of Linux this real time kernel patch set actually provides, and how it would affect your requirements.
It simply sounds as if you want a real time kernel for the sake of having a real time kernel. The simple truths are that:
(1) hard real time kernels are not possible in linux proper itself (there are too many code paths with variable execution times in the critical sections)
(2) therefore, hard real time patches imply a microkernel atop the linux proper which has its own API and executes at a higher priority than the linux kernel proper.
Do you have something which requires real time operation? LinuxMCE will not "magically" work with this kernel as is.
If you do, then of course you can use their API calls (i.e. in listening threads etc.), to make sure certain things always get done on time.
Sorry to deflate your bubble there,
-Thom
|
|
|
|
|
Logged
|
|
|
|
|
JaseP
|
|
« Reply #2 on: June 25, 2012, 04:50:02 pm » |
|
You'd probably have to rebuild the entire set of packages, as there may very well be some components of LinuxMCE that are compiled against the specific kernel and the kernel headers.
Why exactly do you want a real time kernel, anyway? Network latency is going to be a bigger issue than processing latency on a typical LinuxMCE installation. Plus, Real-time doesn't always mean performance,... it actually might make performance worse if some processes are scheduled for a lower latency requirement than others that are really just as important for a system like LinuxMCE.
|
|
|
|
|
Logged
|
See my User page on the LinuxMCE Wiki for a description of my system configuration (click the little globe under my profile pic).
|
|
|
|
tschak909
|
|
« Reply #3 on: June 25, 2012, 05:07:01 pm » |
|
And to reiterate my point, Programs running on hard real time kernel overlays have to conform to the specific API exposed by the kernel (MontaVista's RT-Linux kernels are a prime example of this)
LinuxMCE does not use any of these API calls, and probably won't until there is an actual need for them.
-Thom
|
|
|
|
|
Logged
|
|
|
|
axel
Newbie
Posts: 14
|
|
« Reply #4 on: June 25, 2012, 06:21:56 pm » |
|
Thanks for the clarification.
axel
|
|
|
|
|
Logged
|
|
|
|
|
JaseP
|
|
« Reply #5 on: June 25, 2012, 07:13:54 pm » |
|
As an unnecessary addition to Thom's post, I doubt that LinuxMCE will ever need real-time kernel patches. Things that need real-time kernels are things like anti-lock brakes and aircraft controls, where they have to get it right 100% of the time, and within a specific time frame. Most other uses can be solved by just throwing better hardware at the problem.
The only other use for a real-time kernel I've heard about is in audio & video editing, where latency issues with hardware can cause timing problems with audio,... But we're talking high end editing (professional editing) though.
|
|
|
|
|
Logged
|
See my User page on the LinuxMCE Wiki for a description of my system configuration (click the little globe under my profile pic).
|
|
|
|
Sigg3.net
|
|
« Reply #6 on: September 09, 2012, 03:20:37 pm » |
|
Unless you're composing music (professionally) or other types of rocket science (statistics/huge data sets), you don't need an RT kernel. In fact, musicians get away without RT kernels these days as well...
|
|
|
|
|
Logged
|
|
|
|
|
hari
|
|
« Reply #7 on: September 09, 2012, 04:24:04 pm » |
|
realtime is about guarantees. Average latency might even be worse than with a non-rt kernel. I don't see how we could benefit from using one with lmce.
|
|
|
|
|
Logged
|
|
|
|
|
