The servo thread is scheduled at 1ms intervals, indeed.
This is the thread where LinuxCNC trcks the position of the tool (in the coordinate space) and calculates the next moves.
Basically, the output is the movement speed of the tool in space (and derived from that the speed of each joint) for the next interval.
If this is delayed by 2.5 periods (1ms schedule and 2.5ms lag in your case), that *will* result in problems: no matter how smart the servo thread is, this lag it cannot compensate for; I think. Not entirely sure.
To be honest: I use LinuxCNC only in my hobby shop and tend to be lazy about it: I have not analyzed the server thread and how smart it is at handling lag, i.e. the difference between "i should have run at time x, but current time is x + delta".
Still: a 2.5ms lag is hard or impossible to correct for.
When I had the problem with the SMART readout from the harddrive, the lags were even longer (like 10 times longer) at the peak, but iirc. the 2.5ms could indicate a relation.
But back to the servo thread: the Mesa card runs on its internal crystal oscillator. not really on the 1ms servo schedule.
But the servo thread runs on that schedule (see above), and it gives the commands (speed of each joint) to the card, which then generates step pulses corresponding to that desired speed.
And again: that speed will be the wrong one if the calculation stopped for too long a time (and 2.5ms is too long
My problem with the latency test in 2014 was this: it showed me a measured value and a peak.
But even on a system where the latency test showed no problems, actual LinuxCNC had one. Axis shows this as a popup.
This is easily missed and when you click on it, it goes away and never appears again - because all future errors are ignored. This is a bit dangerous (but I support the design decision behind it, btw.).
And I have at least one system where LinuxCNC runs fine, but the latency test shows large latency peaks.
That btw. was my reason to start this thread back in the day: the fact that the latency test obviously uses a different method to measure the delay between calls to threads, or a different thread setup or some other difference to an actual LinuxCNC thread setup.
So I followed all the advice in the wiki like
- disabling CPU power save and sleep states (since I do not care about saving a Watt there)
- binding Interrupt handling to a core (well - did that, no effect actually, but no harm either)
and in the BIOS setting I disabled everything I thought could influence RT performance: all unnecessary peripherals virtualization etc.
A really unsystematic, shotgun-type approach
So short morale: you must test with an actual machine setup and see, if Axis reports errors.
I ended up running the actual machine (with drives disables to conserve power and spare my nerves of the noise
for a day or so. Just the actual machine config and a repeating G-code sequence resembling actual parts (I just created a file with actual parts in it in CAM and edited it into an endless loop). I let that run as an air cut (no tool) and then disabled the drive power and let the controller run over the weekend.
And when the machine worked fine within my parameters for "fine", I invoked the cardinal rule of IT ("never change a running system") and let layziness win over the engineers desire for asystematic approach to the problem
