This is about using Ingo Molnár's patch. We can get this from..

https://www.kernel.org/pub/linux/kernel/projects/rt/

I expect the version number has to be the same as the current kernel version on the system, which might be a bit of a problem since the numbers all seem to be even, and my distro kernel is 3.5.0-17-generic .. so odd-numbered.

Given is that the kernel is patched to have the RT module attached.
Given we understand that RT real-time is not the same as "low latency", though they often go together.

1. If there is (one) application that must not be pre-empted by any other process, can we force one thread, (of 8 available), to be given over to that application, and still expect "normal" scheduling to apply to all other processes?

2. Does using RT to modify the task scheduling for one application then also require the user to manage priorities of the rest of the system as well?

3. How does the RT priority for an application get invoked from within a program, or perhaps for a program? Is it a compile option?

4. If the RT application finishes quickly, well before the latency deadline, does the thread then become available for other processes?

Please allow that although I am reading as much as I can find on this, I am not so experienced or skilled as a proper programmer. Compiling a kernel I can do. Making a C++ or Java program to use the feature properly is where I need help.

Many thanks ..

FYI, real-time scheduling is almost never used in the context of "a C++ or Java program."

RT has a very, very specific purpose: to provide guarantees that the CPU will respond timely, and in a certain predictable way, following the receipt of a particular interrupt. In most cases, a system that's running an RT kernel does nothing else; it isn't used at the same time for "normal" activities. Instead, it is out there on the front-lines, directly plugged-in to the device that it is to be controlling, and it is talking back to other computers which are using normal schedulers. (Shared-memory is commonly used.)

If you're going to get "real time" responsiveness from the machine, then that's going to necessarily have a rather profound impact on anything else that the same box (or board ...) might be doing, so there's generally nothing else for it to do.

1 members found this post helpful.

If you really need real time then buy a commercial product. Linux had so much trouble with anything real time that they gave up. Everything from drivers to apps need to be written to support real time. Near real time gets past most of those issues.

To be exact, computers are only tested for windows. So so many changes happen inside a computer from gates to pals or proms to firmware between linux and windows. Now you add in untested speeds are required interrupts.

You can try these patches but the actual speed that you get and stability may not be what you might expect.

In a normal real time kernel or microkernel you can't easily change how applications use that. The entire operating system is real time scheduling. The way interrupts come in and are acted upon are in real time. We've use QNX for many decades in automation just for it's real time ability to act upon machine situations.

For most users, a fast system running common kernels with some tweaks will suffice.

Good info. http://www.ibm.com/developerworks/li...al-time-linux/

Thanks for the reply sundialsvcs.
Yes - I do understand about real-time for motion control, especially where various parts have to be in position relative to other parts, such as in multi-axis drives, and "virtual gearboxes" used to run industrial automation machinery.

In this context, the time available is generous, and the motion slow, and generally, all other functions, even on a loaded up machine running Gnome desktop, do not impact the application, which can provide positional demands at 10Hz, or 100Hz, or even 400Hz. Also, the final motion servo loops are handled by a very capable motion controller.

The key requirement, unusual for most motion control, is to have the positional demands met within perhaps 50mS to 100mS of an exact UTC time! Calculating the demands is complete in around 300uS. The phase delay in having the positional loop satified (mechanically) is allowed for by calculating demands set suitably into the future. These values are easily met, even without an RT kernel.

The key point is that without RT, the seemingly "easy" requirement is not guaranteed!. Even if it happens only once a day,and is all over in a short time, it has to happen predictably! We want to avoid it being be pre-empted at the crucial time by other (e.g. network) traffic, or file access, or some other GUI or housekeeping service.

The same application, in a Windows environment, would (mysteriously) fail because of the inability to control application access in time, and is part of the motivation for using a Linux platform. A user GUI becomes much easier to provide when we allow a Linux OS which can in turn command fast hardware controllers as needed. It actually all works! The need is to have more than just a statistical scheduler assurance that the real-time event is not missed. This is not about having it happen at exceptional speed.

Using Mint "Oliva" and can not install Raw Therapee. Any suggestions to a noobe?

Thanks much for the "Good info" link jefro.

At the first try, casually using a generic kernel, the application works OK. That said, we are careful about closing off threads, and avoiding GC garbage collection issues. This is more about the user need for "guarantees" in the face of some extremely unlikely scenarios. For context, the application controls machine motion, needing to be in exact position seconds, or days, or weeks into the future.

Using RT to "guarantee" (even slow) exact timing seems to come with the penalty that all the rest of the carefully thought out "completely fair" scheduling features in the kernel have to be given up.

For the RTLinux module, the rest of "regular" Linux looks like just another thread, and it might be that it is quite easy to use without badly messing with the sensible interrupt handing features of the regular kernel. This is the stuff that I don't yet know.

You will probably find that BFS is sufficient - it really is noticeably smoother than the kernel's default CFS.

I recommend tweaking the BFS default, to:

1 members found this post helpful.

I received a reply about my question on how to install the application called "Raw Therapee" on my MINT "OLIVA" OS COMPUTER. The reply from GThak was concerting the application of using a real time module. Raw Therapee is an application that is for photographers to process their photos taken in the raw format similar to Adobes ACR and Lightroom programs. Please do not confuse with any idea of processing incoming data packets in "Real Time".

oldblueeyes357, not sure but I think you could start a new thread for a question about installing software or an OS. I kind of think your question could possibly be cut out of this thread by a moderator. I am not one.

Maybe just make a new thread.

I agree that you get into scheduler considerations. That too is a concern as brebs points out.

If I were to consider automation and the machine had a common value as in any production line where all material is "just in time", then I'd get a commercial product. Consider QNX maybe.

I might be tempted to also consider a LFS or Gentoo type build. Maybe even a JEOS install might do. Almost any disto you get will have too much set up for a common user and not an industrial control configuration.

You can then find out if you need to step up to soft or hard real time.

1 members found this post helpful.

I have built a couple of Gentoo, but not LFS. With Gentoo, after a long time compiling, it made an old PC quite competitive! There is no question that a hand-tuned Gentoo is about as good as it gets for speed, but I spent much time "learning Gentoo" instead of using it, and I finally got out of my depth trying to handle dependency issues with Portage.

I have been advised to try Arch-Linux, with most programs not needed simply un-installed, and perhaps given a custom kernel compile. So, I much appreciate your suggestion of JeOS, which would seem to be a ready-made option using a stripped-down distro.

Regarding controlling real-time machinery. Fortunately, the really high speed stuff, dealing with velocity loops, encoder pulses, etc. are handled by well developed commercial product. The command machine (Linux), which is the user interface, still has to deliver position demands at (guaranteed) UTC times, but not at a fast rate. The main threat is other telemetry network tasks at the same time. The downside is that to get enough control to be sure the output happens when it has to, (using PREEMPT_RT for one application), then all other scheduling also has to be managed. Maybe using RTLinux unwisely can quickly bring a good working system to a near-standstill!

Exactly so. And this is why, in the few times that I have seen this sort of thing being done, a CPU (circuit board) was dedicated to it. This CPU was slow and cheap because it basically was never given anything else to do. There was one real-time response process, one process serving its needs for data, and a third process talking to the mother-ship. I'm guessing that CPU spent 99.9% of its time doing nothing. A little, "Strawberry Pi"-like daughterboard, running a stripped Linux, and basically being treated as the device-controller board that it effectively was. The onboard software for the card (in EEPROM) could be pushed to it by the host.

Good luck and let us know how it goes.