Unexpected realtime delay error on new Mesa 7i96 install

I feel sure that this has been covered before - but searches have not quite answered my questions, so I am hoping I can get a little guidance from the experts here.

I've been setting up a new LinuxCNC installation - my very first after using Mach3 for some years. It will be driving a Mesa 7i96 card. I have everything installed as per the usual instructions - Debian Stretch with pre-empt -rt, LinuxCNC 2.8. I have the network set up and talking with the Mesa card. I've done the tweaks like disabling IRQ coalescing, as I am using an Intel chipset machine.

The problem occurs when running up LinuxCNC, where I get an "Unexpected realtime delay on task 0 with period 1000000" error. This is soon followed by a second error, "hm2/hm2_7i96.0: error finishing read! iter=8". Photo attached.

I am well aware that it could be due to the PC I am using, which is a pretty old ASUS EEE box B202, and maybe not up to the task. Of course I have run the latency test - results attached. I also ran pings, and got results around the 300us level. Is the PC my problem, and not powerful enough?

Many thanks in advance - any guidance would be much appreciated.

Graeme

Attachments didn't come through - it said they were too large, despite being well under the 1.6MB stated. More help required...?!

A 300 usec ping time is pretty dismal

I suspect the EEE is just too slow to run a 1 KHz servo thread over Ethernet

You might try a 2 ms (2000000 ns) servo thread

Many thanks for the fast response!

I've seen you say that previously, and I'd ask for advice on improving it - but I suspect it is simply down to the choice of machine. I will however try what you suggest and see if it helps. In some ways, even if I can get motors spinning at this stage - with this underpowered machine - it would allow me to progress my project, giving me time to research and choose a better PC.

As I said before, I couldn't attach my images - so I'll quote my latency numbers instead;

Servo thread (1ms) - Max interval = 1241285 - Max Jitter = 242958.

Do they support the "too slow" theory?

Graeme

Yeah thats pretty bad
Are you sure you have all power management disabled?
(any speed switching, C states >C1 etc)

I made the necessary C state additions to the grub file, as covered elsewhere in the forum. And there's not a whole lot to tweak in the BIOS wrt power settings. Disappointing really!

One thing that has puzzled me, on which you may be able to offer advice. There are latency ranges specified that are required for software pulse generation - and that makes sense, as all the work is done in that loop. But I haven't seen any figures that are sustainable for pulse generation in Mesa cards. I assume there is more latitude? But how bad can you get before it's not going to work?

For Mesa Ethernet cards, the latency + transport time must be less than the servo period
(normally 1 ms). For slower systems you can lower the servo thread rate, 2 ms works fine
for many machines. A trade-off with a slower servo thread is that the number of velocity
steps during acceleration is lowered, but this is mainly an issue with high acceleration
machines. The maximum step rate is not affected by latency or servo thread period.

That makes sense. So in my case, I'm burning 30% of my time just talking with the Mesa card. Putting it that way, I can see why ping times are a big deal!

Can I also ask what the difference between Max Interval and Max Jitter are in the Latency Test? Which is the critical number here?

its probably a bit worse than that since the Ethernet driver does three
operations per servo thread:
Transmit input data request
Receive input data
(LinuxCNC does its internal calculations)
Transmit output data

So if you have a 300 usec ping time (1 write+ 1 read ), LinuxCNCs access time might be 600 usec, now add 240 usec of jitter and you can see you are close to having used up all your time.

The max interval is bascally the nominal period + the max jitter

I see what you mean!

So, I just tried upping the servo thread time to 2ms, and it removed the "Unexpected realtime delay...." error. A step forwards!

However, after a few seconds, the "hm2/hm2_7i96.0: error finishing read! iter=8" popped up. I forged ahead anyway, homed the axes, and tried an MDI move. Unfortunately that generated a couple of joint tracking errors - one on each axis I was moving. I figured my max step speed may be too high now, so I dropped it on all axes to 500mm/min. But that didn't fix it.

BTW, the red LED next but one to the yellow "init" LED lights when I get the finishing read error, and never disappears. I presume this is akin to the watchdog biting? I fixed the biting problem by upping the timeout to 50ms. That was last night's progress.....

Any thoughts?