Ruckig broke RTAI

[BsAtHome]

The inclusion of the type 1 jerk limited trajectory planner, with inclusion of the ruckig code, completely break compiling RTAI. The problem is that ruckig is C++ code and that you cannot have in the kernel. Also, the code uses libc calls not available in kernel land.

The solution is one of:

1. remove the ruckig code for RTAI (removing this TP)
2. rewrite the ruckig code as plain C
3. take the trajectory planner out of the kernel and RT

Option 3 would be best, but either way, RTAI remains broken until this issue is solved.

[edit]
Or option 4: remove RTAI before the bitrot infects other parts.

[NTULINUX]

As long as the classic TP works. I wouldn't remove support for RTAI just yet, I think Andy still uses it. Some systems do not play nice with PREEMPT_RT as well due to BIOS or motherboard issues.

[BsAtHome]

As long as the classic TP works. I wouldn't remove support for RTAI just yet, I think Andy still uses it.

Yes, but he surely hasn't compiled master for RTAI recently or the trouble would have been obvious. And he himself merged the ruckig code :-)

The problem is that it needs to be compiled out for RTAI to function. That is a strategically losing proposition in master and makes things utterly ugly and complex. There is supposed to be plugability of the TP, but afaics, the way it is compiled suggests otherwise.

Some systems do not play nice with PREEMPT_RT as well due to BIOS or motherboard issues.

That is the first time I hear about that... Can you be more specific? Do you mean hardware no longer supported by newer kernels or what?

[NTULINUX]

That is the first time I hear about that... Can you be more specific? Do you mean hardware no longer supported by newer kernels or what?

Latency will be over a million microseconds with PREEMPT_RT but under 10 with RTAI. It's obviously not every system but having RTAI as a fallback will enable systems that absolutely cannot get low latency with PREEMPT_RT regardless of BIOS settings can still use RTAI and get quite reasonable scores. The Intel system I had a few months ago was an i5-1135g7, speed stepping, removing all the power management/savings things, nothing worked.

[BsAtHome]

Latency will be over a million microseconds with PREEMPT_RT...

One million microseconds is one second. That number you mention here is either very wrong or hyperbole.

And did you boot the same kernel for RTAI and RT_PREEMPT testing? Kernel versions do matter.

[NTULINUX]

Latency will be over a million microseconds with PREEMPT_RT...

One million microseconds is one second. That number you mention here is either very wrong or hyperbole.

And did you boot the same kernel for RTAI and RT_PREEMPT testing? Kernel versions do matter.

I meant nanoseconds, sorry! Also, RTAI and PREEMPT_RT cannot be patched together in the same kernel tree. I tried to get it going but hit a hurdle with mutexes at the very end.

[BsAtHome]

You don't need to apply both patches at the same time. You just need to use the same stock kernel twice and patch one with RATI and the other with RT_PREEMPT.

[NTULINUX]

This has been an ongoing issue where some systems just don't play well with RTAI and others don't with PREEMPT_RT dating back to 2.6 kernels. Some BIOSes also don't allow you to adjust what's needed to satisfy either or's requirements. I did manage to find the last working checkout of master for RTAI though #3873 (comment) There's also some systems that have horrible latency for both, RTAI typically being lower in most cases hence why I'm not big on having it removed completely. It's at very least, a good fail-safe for when PREEMPT_RT does not work.

[BsAtHome]

You are welcome to fix the issue and remove the new TP.

[NTULINUX]

I've been working on it but about to give up. I'm actually working on a project to try and get better latency in PREEMPT_RT in case RTAI does in fact get dropped.

[andypugh]

Some systems do not play nice with PREEMPT_RT as well due to BIOS or motherboard issues.

That is the first time I hear about that... Can you be more specific?

There are some drivers that are not compiled for preempt-rt.

https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L939

It's likely that none of them are currently being used anywhere, at least not on hardware supported by Master/Trixie.

But there definitely are users who insist that they need RTAI.

[NTULINUX]

Well the problem is that the new TP is intertwined with the old one... So removing the source files won't help from the build.

[BsAtHome]

Well the problem is that the new TP is intertwined with the old one... So removing the source files won't help from the build.

I thought I already said that? #3875 (comment)

[NTULINUX]

What I'm trying to say is that I'm stuck because of the way it's plugged in, I've been working on this for hours and got hardly anywhere.