Motherboard with bad latency, usable anyway?

Working on a new installation.
It will be a XYZS mill with step motor drives via a Mesa 6i25 board.

The motherboard I am trying is an old Intel Core Duo. (Lenovo G31T-LM)
It has decent latency at about 15000 but every 7 seconds there is a 200000 ns spike. Nothing worse even after several hours.
I have tried with Debian Wheezy PREEMT RT and also Ubuntu with RTAI, both same performance.
I have tried with onboard video and a PCI-E video card.

BIOS has very few things to set, I have disabled what can be disabled. It can possibly be an SMI thing. Only thing that can be set in that area is "Fan speed: low-normal-high"

Is it a bad idea to run Axis on this board with a servo thread at 1ms and no base thread?

Its OK with a hardware stepgen or servo system

I would bug that lazy PCW guy for a DPLL enabled firmware config so the
200 usec latency doesn't cause a delay in the position read part of the control loop

Do I read your comment like this?

Even if we do not miss out a complete 1 ms servo thread interrupt, there will be a miscalculation for instance in a PID block if the interrupt as sigificantlly off time??

Yes, though it may not be too significant depending on your machines speed and required precision.

For example, with a 200 usec latency spike and 120 IPM (2 IPS) motion, the PID loop
would see a bogus 0.4 mill error and then proceed to try and correct it, causing a real error.

Typically large latency spikes are only one cycle long so you end up with a
little high frequency white noise added to your velocity but no long term deviations.

There are a number of things that can be done to improve the situation, the first is to use as PID based step/dir control loop instead of the drivers built in position mode. this means you can much finer control of the position feedback loop.
so for example you can set the PIDs maximum error to some small number so that large position errors due to latencies are "clipped"

You could also use a FPGA configuration with a DPLL. The DPLL locks onto LinuxCNCs servo thread rate and
triggers position sampling for the stepgenerators and encoders a presettable time before the servo thread runs.
This reduces sampling jitter to the nS range. The DPLL sampling option is standard on Mesa Ethernet FPGA configs
(as these have higher inherent jitter) but can be added to any configuration.

PS: If you wish to learn about about your latency statistics, run the latency-histogram:

latency-histogram --nobase

Suppose I have a stepper motor controlled in the style defined by pncconf, motion controller feeding into a PID feeding into a 5i25 hardware step control. The PID block has FF=1, P=1000 everything else zero. There is only a servo loop at 1ms.

What would be the consequences of
(a) One realtime tick being off by 200us from the nominal 1000us, once every 7 seconds?
(b) The tick being off by more than 1000us, so one tick is missed completely? (If that is what happens)

There is a position feedback from stepgen to the PID, but the stepgen has a velocity command as input, will I have a glitch there? Not sure if the 5i25 FPGA receives the realtime clock tick.

As I tried t explain above, the error in the step pulse stream will be proportional to the velocity * latency
(and in fact very close to velocity*latency if P = Servo-thread rate )

if you miss an entire tic you will have the same error, ~velocity*latency
but LinuxCNC will also report a real time delay

( If you have ms delays you need to fix the issue (SMI?) )

andypugh wrote:

PCW wrote:

( If you have ms delays you need to fix the issue (SMI?) )

wiki.linuxcnc.org/cgi-bin/wiki.pl?Fixing...bout_2008_emc2_2_3_0

(but note that you can ignore all the compile instructions in modern versions of LinuxCNC, the module is already included)

I installed rtai_smi into rtapi.conf, this made a dramatic difference.

Latency is down from 200 us to 12 us even after an hour of Youtube and other surfing. This latency will be excellent with my application.

NOTE
There is a line with only a period printed to <stdout> each time rtai starts now. Possibly this is done by rtai_smi. Shows up when starting halrun or latency-histogram.