Going from Devian 10 to 12 has created problems

Surely you can have that document as an attachment?

"As I said 2 cores may not be enough anymore"

Why does Microsoft come to mind here? Doubtless the folks at Debian would say that Bookworm is an improvement on Buster, but I'd question how a system that may require more advanced hardware to do exactly the same job can be called an "improvement". I'm quite happy with my little industrial PC. It's a perfect fit for my workshop environment (small, fanless) and experience has proved that it is quite capable of running Linux CNC. So to my mind the problem is not my PC but Bookworm, and if all else fails I'm going to simply revert to the Linux 2.8.2 Buster distribution and accept that my system will have to stand pat as the Debian world moves on. End of rant.

It's more of a kernel/driver issue than hardware/Linux Distribution issue.

Are you using isolcpus?

 

Yes, isolcpus is set to 1.

I think that the ping test is a smoking gun.  If the results can be explained and a solution found I suspect (hope?) that everything else will fall into place.  The attached is typical:



It's beyond belief that a round trip that typically takes about 0.1 ms can sometimes take 26ms.  And note that the round trip clearly took more than 1ms quite a few times (the total test took more than the 60027ms it would have taken had there just been one bad ping).  What could possibly be causing this to happen?  It's not as if anything else was going on - apart from the test the computer was essentially idling.

I've paid my $2 Australian and have had a crack at IRQ affinity.  But the solution proposed in the forum piece is of absolutely no use to me.  irqbalance was not even active on my machine, and when I tried to install it it would not activate because the condition "CPUs=>1" was not met.  Which does make sense - if you've only got two CPU's and you're not going to allow interrupts on one of them there isn't much scope for balancing. In practice interrupts are distributed between the two CPU's (note: they are evidently NOT excluded from the isolated CPU).  See the attached file.

 

Presumably my goal  should be to tie interrupt 29 with CPU 1 and all other interrupts with CPU 0.  But how can this be achieved?  I don't even have a /proc/irq folder, and even if I did I suspect that in the absence of irqbalance creating appropriate files wouldn't do me any good.  And presumably I should also be running the ping test on the isolated CPU.  Does the 99 priority force this to happen, or is something else required?

 

You might try this script to pin the Ethernet interrupt to the last CPU

 

chmod +x pinirq.txt

sudo ./pinirq.txt enp1s0

(might also be enp1)
 

For what I want to do, the script boils down to

echo 2 > /proc/irq/29/smp-affinity

I've tried this and it doesn't work. I get "permission denied" (whether or not I use sudo), presumably because folder irq don't exist. And even if I were to create folder irq, and create a folder 29 within it, I can't see how just creating a file is going to change anything. Something has to use the file, and in this case I think that that something is irqbalance, which as I've mentioned doesn't exist and can't be made to exist.

What does my script do?

(sudo is a bit funny with some command lines)

PCW wrote:

It's more of a kernel/driver issue than hardware/Linux Distribution issue.
 

I think the world has got more complex and there are standards like energy efficient Ethernet (EEE) that the kernel has to support today in this world of power conservation. they all add up.rtt min/avg/max/mdev = 0.100/0.114/26.854/0.321 ms, pipe 2 As you say it is sometimes slow. This can be affected by the initial ping when its connecting but it can be EEE kicking in. Check the doc for how to disable that. (I am not convinced that it is still disabled by default.

One of the issues here is that there is no RT ethernet drivers. Ethercat gets around this by writing their own drivers but for the most part now depends on the generic ethercat driver which is not real time which they say is mostly good enough (except for some realtek). 

The only other trick which has worked with 2 core PC's in the past is to compile the kernel yourself because Debian seems to make some odd choices in their kernel version. If you go down this path, I would download the 6.1.17 kernel source and the matching 6.1.17 RT patch. I would do this to build a Deb on another PC with more cores or it will take you many hours/ even days. Perhaps PCW can provide some guidance on the necessary steps. Unfortunately, I have lost my scripts....

Ooops, I got that wrong go for kernel 6.16

Here's a script for 6.17-rc1-rt1 that works for me on Mint 22.1
There may well be different dependencies on your system

 

unzip, chmod +x  then sudo

And yes, Debian does seem to have a talent for making awful RT kernels