Latency problems Intel motherboard

Hello,
I'm using UBUNTU lucid 10.04 and EMC2.4.3. My old Asus A7NX-X motherboard died, and I replaced it with IBM 8305-81U. Then ran the latency test which was returning 3ms peak timings. I did a memtest all day and it passed OK. The sound and ACPI are disabled in the BIOS. I changed out the computer with another IBM, but results are the same. I read up about the Intel ICH4 controller and SMI interrupts. as descrbed here in step 4:
wiki.linuxcnc.org/emcinfo.pl?FixingSMIIssues
I then hand edited the rtapi.conf file to include the smi component to inhibit the SMI interrupt. But after starting EMC2 and entering the lsmod command in a terminal window, I found the module had failed to load for some reason. EMC2 will start and run the same and still gives the same RTAPI error messages.
Would anyone advise me about how to get the SMI module to load in rtapi.conf? It loolks like it's a common fault with the Intel motherboards, and I'm wondering if I can beat it with the SMI interrupt disable, or is it worth all the hassle.
I never realized how good the old Asus motherboard was unitil I had to replace it. After reading of similar latency woes I wonder if it would be simpler to just purchase the newer Intel Atom D525MWV board and be done with it. Apparently, it's not plagued with the SMI. Thanks for reading.
regards,
Denis

Hi

First off you need to be sure that SMI is the issue you have, not just a frequently discussed problem with that MB.

Execute /usr/realtime-(kernelversion)-rtai/testsuite/user/latency/run inside a terminal
This will run a latency test with a per second printout.

Watch lat max and if SMI is the problem, every 32 or possibly 64 seconds, there will be a big spike in latency figures.

If this does not occur at this or another regularly timed interval, SMI is not the problem.

It will also help you separate background latency from spikes and get a picture as to whether the MB has decent latency ( and is therefore worth persevering with) with SMI taken out of the equation.

My setup is considerably different to a standard install of EMC, so I will do a vanilla install of 10.4 on another partition and come back to you regards actually loading rtai_smi.ko.

Regards the Intel 525.
I have built one albeit not for use with EMC. It comes highly recommended by those that have used it however.
It is rock solid and silent (I used a SSD) and the big advantage regards EMC, is not only good latency, but that it is very small and requires only a 12v PSU, so can be built into a controller cabinet etc and integrated within the machine itself.

regards

You may also want to try the latency test on 8.04, it does seem to work better on some hardware.

Rick G

I will do a vanilla install of 10.4 on another partition and come back to you regards actually loading rtai_smi.ko.

Unfortunately could not do this, I cannot load rtai_smi.ko either from rtai.conf, from /realtime-xxxxxx/bin/setsmi or on the commandline, always get error device not found.

Looks like the module may be chipset specific from other posts, has to be an Intel one using SMI, so I can't even test it.

EMC2 will start and run the same and still gives the same RTAPI error messages.

I am a bit surprised that EMC runs when the attempt to load rtai_smi.ko fails, this was a fatal error on my machine and in other posts I checked.

Normally seem to get something like
insmod: error inserting '/usr/realtime-2.6.32-122-rtai/modules/rtai_smi.ko': -1 No such device
PID TTY STAT TIME COMMAND
Stopping realtime threads
Unloading hal components
ERROR: Module hal_lib does not exist in /proc/modules
ERROR: Module rtapi does not exist in /proc/modules
ERROR: Module rtai_smi does not exist in /proc/modules

Try running emc from a terminal with the modified rtai_conf in place and see what it tells you about loading the module.

regards

Hi Arceye,
thanks for the reply. I got it running OK now I think, here's what worked for me. I could still start EMC2 from a terminal window or the desktop GUI. Each time it ran, entering " lsmod |grep rtapi " from a terminal shows that it failed to load the rtai_smi.ko module. From what I read the intel MB chip responsible for SMI is 82801DB, and it's on this MB.
I killed EMC2, and tried to run /usr/realtime-(kernelversion)-rtai/testsuite/user/latency/run inside a terminal, but it returned no such file/directory.
I entered latency-test in a terminal window and it ran the Hal latency test w
hich gave showed 370 microsecond peaks about every 30 seconds. I figured if it could load the modules/rtai_smi.ko, perhaps that would take care of it.

Here's where I messed up and my fix. I examined step 4 here:
wiki.linuxcnc.org/emcinfo.pl?FixingSMIIssues
and noticed that there are actually 2 changes that have to be made in
rtapi.conf and I had only provided the path and missed including ' rtai_smi ' in the MODULE list. I had missed the MODULES addition because it was printed small case instead of capitals.

The next latency test returned 15.2 uS Base threads. Then I ran the EMC2 stepconf program and entered 20000ns for a base thread value, and started EMC2 and so far so good, no rtapi error messages. I tried the other IBM computer with the same EMC2 which is on a CF card, and it runs also with an even lower 14.7uS latency. This second machine has an external video card, the first IBM had integrated video.
So now that EMC2 appears to be running OK, next is the thermal issues. Intel cautions there might be overheating which SMI is supposed to deal with them. So far it's not running any warmer than before. Can I hard wire all the fans to run full speed to play it safe?
Thanks for the help.
cheers,
Denis
~
~

Hi

Glad you got it sorted, we both learnt something on the way. It never occurred to me that the module would not load on my system, I just didn't expect it to do anything.

I killed EMC2, and tried to run /usr/realtime-(kernelversion)-rtai/testsuite/user/latency/run inside a terminal, but it returned no such file/directory.

I assume you substituted 2.6.32-122 for (kernelversion) It should be there on a normal installation, but no matter, you have sorted it now.

So far it's not running any warmer than before. Can I hard wire all the fans to run full speed to play it safe?

A lot depends upon the ambient temperatures and the amount of free air circulation around the computer cabinet.
Rather than muck about with CPU fans, in the past I have just added another 4" case fan, set to extract, if I think things will get too hot.

Depending upon what BIOS you have, you may be able adjust the temperature thresholds for fan activation, or even just set an alarm if a temperature is exceeded.
The latter might give peace of mind whilst you are testing, but the older the machine and the BIOS the less likely you are to have this facility.

The next latency test returned 15.2 uS Base threads. Then I ran the EMC2 stepconf program and entered 20000ns for a base thread value,

That might be rather ambitious.
You need to read
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Twe...ftwareStepGeneration
and
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Stepper_Drive_Timing

My rule of thumb 'guesstimate ' as a starting point for a base thread value is base thread latency x 3, ie 45,000ns in your case.
Only once you have made the calculations can you arrive at the theoretical optimum and even then it may need adjusting upwards if your hardware does not conform exactly to the specs for it.

Looks like you have a suitable candidate computer, happy tweaking!

regards

I thought that the normal procedure was to set the base thread to around 1 x the latency. I know that this makes absolutely no sense, and it always puzzled me, but then I stopped having a base thread and lost interest

With a base latency of 15000, if he used that as his base thread setting, Axis might not even start.

When I started out with my first machine, my workshop computer give consistent 11,500 base latency heavily loaded.

I tried a starting point of 20,000 for the base thread and could not start Axis properly.

The theoretical figure for my steppers and drivers was 30,000 but based upon incomplete data and guesstimates from similar hardware.
In practice this threw occasional RT errors and trial and error came to 35,000 as a good stable and fast stepping figure.

Since then, I have used the 3 x 'rule' and always managed to get a running system which could then be fine tuned.
Most of my hardware is sourced from the same places so the calculations are probably quite similar, which doubtless helps.

Some day I may lose my base thread too....