Another realtime delay question - Mesa card

To check:

ethtool -c [your ethernet device name]

you may need

/sbin/ethtool -c [your ethernet device name]

on debian

Fascinating, Tommy. Yes I've noticed, and in fact gained an incredible amount of knowledge based on your contributions here, for one I'm grateful for that.

A bit surprised to hear about your terrorism/fast-demolition skillset (!!), less on the chemical abuse though; also got severely poisoned when much younger, LSD it was if my memory serves well lol Likewise, BCompSc and career in the public sector here too (interesting). Keep it up ~fanclub. 

@rodw: I did install grub-customizer now and did change to the second option you mentionned as I did find cstate in the bios, and then also changed the interfaces file again from eth1 to enp1s0.
Rebooted, no difference in latency, if anything maybe slightly worst.

and output from ethtool -c



@Mecanix: How shall I try and modify the interface parameters to match your example?


Also, sorry to insist with my naivety, but what are the actual practical consequences of this bad timing on the machining process? What are the risks of keeping it at 80000 latency? I honestly have been getting this error for a while before getting myself to post here. And I haven't noticed any problem with the machine, keeping tolerances in the thousands of mm and speed of 3000 mm/m.

On second thoughts I always bad latency tests with this HW, but I don't think I was getting this error as much before upgrading to bookworm and 2.9. I definitely had to change the servo thread timing only after upgrade. Does that help diagnose?

Run this and share a screen dump. It will confirm isolcpus is set

I hve never used a 2 core machine with linuxcnc, mostly 4 core celerons J1900 and up. I kind of think the 2 cores are at the end of life  but a few people have got them going. Generally with a compiled kernel which is your next step. There was a thread recently where somebody showed how to compile the 6.6 kernel

really? Honestly, I'm think I^m the nurdy type but this super low level stuff is a bit much still.

here is the screenshot

 

Are you still getting realtime delays?
In answer to your question latency under 150000 even up to 200000  are generally OK.

You need to run the test for longer and run a few glxgears

Ok, I'm gonna run the histogram for a while with some glxgears. I'll come back to you with the results.

In the meanwhile can we do a bit of vulgarization here?

Tell me if I get this right:
From machine to computer: The servo needs (I guess) 230V with a varied frequency to control its speed (I guess that is pulsed in some way, I really never looked into it). The servo controller supplies this to the motor, following instructions in the form of 5V DC pulses coming at high speed from the Mesa card. This timing is obviously critical, hence the dedicated mesa card. The Mesa is talking to the computer through the ethernet port. What's happening there: does the computer send straight Gcode (in binary form or something) or does it itself send pulses that are then buffered in the mesa)? What translation happens from the Gcode and where? What's the risk of a realtime delay in this communication? To miss a pulse? To miss a whole Gcode line? To crash?

So herewith is the new screenshot after a while and with 5 glxgears. So it's quite exactly 150000 right?
I still get realtime error messages.
Here is the timing in the ini file. should I change it?


 

Otherwise, should I compile a Kernel? I must say I like high level stuff like python coding, but words like kernel and compile together give me shivers.

Another option would be to get something like this:

www.prodimex.ch/gigabyte-brix-gb-bace-31...ace-3160-109329.html

quad core. and migrate the ssd and the ram from the one I have. Would this make sense?

You have not said if you are still getting real time errors. It might now be OK.

The Gigabyt N3160 is gennerally fine. I have used one for several years.
They have a realtek driver so you will probably have to install the r8i68-dkms driver.