RPi + Mesa + high CPU load gives stepper stuttering

I think I've probably been having this problem since I first started using a raspberry pi to drive my mill.  I noticed some CPU-related "hiccups" from the motors early on, and got rid of some background processes that were causing them, and didn't think anything more about it.  But today I noticed some new stutters/hiccups from the motors, and while trying to reproduce, started dragging the Axis window around on the screen.

Well, hoo boy...  the mill sure didn't like that!  Obviously, system load is affecting LinuxCNC in ways that it shouldn't.

So.  I must be doing something wrong, because I assume other people run X11 on their RPi HDMI monitor, and don't have this symptom?

I'm running the RPi 2.9.4 .iso (kernel was built 1/27/2025).

It's driving a Mesa 7i96.  I don't use wireless.  One ethernet is the built-in Pi interface, the other is a reliable USB/Ethernet dongle.  It doesn't matter which drives the Mesa, the symptom remains.

My cmdline.txt looks like this:
Most of that cmdline came from other posts on the forum.

I tried adjusting the IRQ affinity for the Mesa ethernet, to move those interrupts onto core 3 along with the rest of the real-time stuff, but that didn't help.

I'm sure I can find a PC that will work (I did some tests today on an older Thinkpad, with surprisingly good results), but I use the RPi gpio pins to help work around a LinuxCNC shortcoming, and I'd rather not lose that.  I will if I have to, though.

Any ideas, suggestions for things to try?

 

Another data point: as mentioned in another thread recently, I've had to bump my SERVO_PERIOD up to 2ms to avoid runtime errors. Perhaps related, I'm guessing.

And one more data point: running up to 5 glxgears while the motors are moving doesn't cause the problem. But if I drag those windows around? Lots of bad noises from the motors. I've run that many glxgears, and dragged them around, many times when doing the latency test. There's never been an effect. But there is on the actual motors.

I would first try setting the DPLL read time earlier, say -200 usec

If the host has a lot of latency issues, the servo thread invocation
time can be delayed quite a bit from its nominal time and this can
cause enough baseline wander in the DPLL tracking to read before
the the DPLL trigger latch time when the delay goes away.

Also make sure that:

hm2_7i96.0.packet-error-total

is 0 (If not, the network latency is so bad that packets are being dropped)

 

Heh. It's as if you actually know a lot about this, and have been doing it a long time.

I changed hm2_7i96.0.dpll.01.timer-us from -50 to -250, and the symptom went away. (First try, I changed all 4 dpll values by -200, but it turned out changing the others wasn't needed. I'm guessing they're not used?)

Thanks! Oh -- also, hm2_7i96.0.packet-error-total stays 0.

paul
p.s. Best tech support ever...