I've read documentation and tried setting a critical process with real-time attributes, ex.:

That change in priority can be seen within top.

I just was wondering what's the difference between seting "niceness" priority with nice/renice and change chrt attibuttes. I suppoused chrt offers better "fine tune"... Are there other differences?

Regards,
Matías

One thing that you need to (please!) remember about Linux is that it is not fundamentally designed to be a "real-time" operating system.

Yes, it has certain available features which are "nods in that general direction," but (IMHO) a true "real-time OS" cannot be "general purpose" and vice-versa. I believe that an OS-designer must, fairly early on, choose one direction or the other and then remain consistent with that direction. (Lest you wind up failing to satisfy both, at once!)

(Again, IMHO...) A true RTOS is a very specialized beast: you have a machine to control, and human beings are potentially at risk of their lives if you screw up. The system that is controlled by the RTOS does nothing else. A general-purpose operating system such as Linux has a much broader set of objectives, and it must be allowed certain concessions in order to meet those objectives: concessions which an RTOS could not allow if it is to to meet its objectives. "And never the twain shall meet..."

Thanks a lot for your explanation and considerations on designs of RTOS and General porpouse OS, found it very interesting.

My doubt is if are there any difference between the way linux kernel prioritizes using chrt or nice.

Regards,
Matías

Well... man chrt

The main purpose of this command is to set the scheduling algorithm that is to be used for a particular process.

The fly in this ointment, of course, is that in an actual RTOS situation, it really doesn't work well to set the algorithm for "one process," or even for a group of processes, when other processes on the same system don't work the same way. Somebody's gonna get the short end of the stick.

If you look at the scheduling behavior of a given process, when it has control and as long as it has control, then, yes, it will get dispatched as the chosen algorithm indicates. However, if you look at the behavior of the system over time, you now see a curious and rather dysfunctional (IMHO) admixture... kind of like a committee meeting.

Of course, Linux is doing the best that it can, given the (intentional) design that it has. You are putting apples and oranges together in the same bushel basket, and it's trying its best to make tasty juice out of them, but (IMHO) it's a problem that really can't be solved.

I understood... Thanks a lot for your kind explanation!!
With the few test I did I didn't find big difference after changing schedulling algorithm and giving extra priority for on of my processes. But may be that's because of the "nature" of the process or related to the facts you exposed me.

Thanks a lot. Regards,
Matías

Glad to have (maybe) helped...

My general thought on the matter is that, if you have a multi-million dollar very dangerous machine to control, use a purpose-built RTOS to control that machine ... (pretty please) ... and then, use a general-purpose OS such as Linux (of course...) running on a different circuit-board in the same machine perhaps, to talk to it. (Using the equally-peculiar software that the RTOS vendor has provided expressly for that purpose.)

One machine (IMHO) just can't be asked to satisfy both sets of requirements at once. It doesn't make sense. But two machines can, and now it does make sense. Thankfully, "machines" are relatively easy to come by these days.