Systematic approach to tracking down latency issue

The wiki has a page on SMI problems.

wiki.linuxcnc.org/cgi-bin/wiki.pl?FixingSMIIssues

JT

Hi Hase,

I know this thread stopped a few years ago. Did you ever solve this issue? I have just realised I have a similar problem, good latency but with unbearable spikes. Mostly, spikes seem coincidental to actions and repeating, like disk accessing, doesn’t repeat the spike. I’ve tried 2 graphics cards with ATI better than NVidia but clearly the cause of spikes.

Any, I’d love to know if you had any joy here.

Cheers
Richard

* but not clearly the cause of spikes. I should add these spikes do not occur very often. Maybe once in 5 or 10 minutes.

I never really found a systematic way.
I gave up when I found all the measurement programs to show not only different but contradictionary measurements.
Also, my mesurements using external hardware I hacked together - like comparing a software-generated pin-toggle in every cycle of the base thread to a frequency generator - did not help.
I was also unable to rebuild even an official kernel - that is: one shipped with LinuxCNC.

I can confirm, that all Nvidia graphics I tried are making the PC useless for LinuxCNC.
Stay away from anything Nvidia.

The Radeons work well for me.

One reason I was able to identify through elimination: when I swapped an older hard drive for one supporting SMART, a perfectly fine working controller became useless.
Turning off SMART support in the BIOS Setup fixed it.
Obviously, handling SMART diagnosis has a higher priority than the timer interrupt - which it should not have.

As a result of all my frustration I just switched to Mesa FPGA cards for step generation.
Their documentation was a bit confusing at first, but eventually I figured it out.
I have one controller with a PCI FPGA card and the Mesa driver/breakout card, another one with just the (cheap!) FPGA card any my own little driver/breakout board.

In both controllers the base thread is now empty except for a pin toggle on a parallel port. I feed this 50%-duty PWM to an external watchdog (a window comparator checking the analog voltage to be between 40% and 60% logic level of the parport tripping an RS-Flipflop; so if the base thread stops completely, the watchdog turns off the power to the drives and spindle).
A bit of jitter in this function is no problem (covered by the rather large window) and the FPGA make silky-smooth steps

Any btw: I stocked up on Core-II-Duo based Dell Optiplexes and Fujitsus when they were still available.
They have enough CPU horsepower for LinuxCNC with Axis and perform much better latency-wise than anything more modern I tried.
The more nifty stuff the chipset has built-in, the more hickups the BIOS seems to be able to cause.

But again: sorry, I have no systematic, just anecdotal evidence.

hase wrote: Any btw: I stocked up on Core-II-Duo based Dell Optiplexes and Fujitsus when they were still available.
They have enough CPU horsepower for LinuxCNC with Axis and perform much better latency-wise than anything more modern I tried.

I did the same thing with Dell, but that stock is wearing thin lately !
Oh yeah, stay away from new Nvidia cards. New Radeon works fine......until you try to install the 3D drivers, a new install is inevitable ! Have an RX580 in the main computer that i use daily.

Thanks for your reply Hase.

I'm going to check memory usage and the SMART capability of hard drive.

I use the Mesa FPGA boards (5i25 specifically) at work to run automation prototypes. No problems using those. I think I'll buy one. They run on a 1ms servo thread, right? I left my machine with the latency profiler running over the course of about 9-10 hours and found a max spiked latency of 2.5ms - this could be a problem with the FPGA boards. Any thoughts about how they might function with a late latency?

Anyway, thanks again for all your thoughts.

Richard