ubuntu 14.04.1 linuxcnc help

Jason
I learned about SMICRTL here

www.10k3d.com/

The web page has a link on it about SMICRTL risks and implications of doing so.

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

Some of the info is out dated for the way we installed it, but heat can be a problem

On Zultron git hub, (aka John Morris well respected name in Machinekit community)

smictrl Debian packaging

smictrl is an SMI enable register manipulation tool by Jan Kiszka

It is used to disable system management interrupts on some x86
chipsets that can cause unacceptably high latency spikes in real-time
applications.

I am surprised it worked on 64bit system
Tim

Yes i had read those warnings. ive been periodically checking the cpu temps, and for the most part they had not been to high, except when, for whatever reason, the system monitor claimed i was running 1 core at 200%.
I was suprised to hear you had left your computer on test and left it, although i dont remember if you said that it was a laptop as well, or a desktop. Im thinking its a desktop if your trusting it like that.
Rythm box seems to work ok, that may be wht i didnt notice such a large spike like you had.
I meant 32 bit version in my previous post.
Ive been looking for a script for grub to set the fan to a higher speed, but most of the results are for lowering the speed, due to bugs in linux on laptops.
You may get small spikes with psensor, as it makes calls to the cpu, gpu and various other sensors.
I think you can turn it off for the actual tests, and just check the temp in between or run dummy tests where you are really just checking to see if it heats up too much.
THis has been an interesting day for me. xorg was causing some of the latency spikes so i decided to try to us the nvidia driver suggested by ubuntu, this caused a blank sccreen after startup, and i could get it to start.
came home to my trucks leaf spring breaking in the drive, and after i got out to see what happened, i hopped back in to turn it off just to see the lites on for battery and brakes.
hope your day is better but it looks like i wont be doing much tonight...

I did have a chance to reload ubuntu and run the ammended script as it was written and was thinking it might not be a bad idea to wait until after linuxcnc has been installed as running one core for this operation is painstakenly slow.

Jason really sorry to hear about your ride

As far as all latency fixes we have been doing it would not matter if done after Linuxcnc was installed.
A note for you also the Deb files that you create can be saved to USB stick and reused if reloading same OS and flavor.
Just run script first then install Deb's

I have post the results of my 11 hour test on 64 bit system in post

forum.linuxcnc.org/forum/9-installing-li...-help?start=90#66562

Now to Install Rtai 32 bit system and do same testing to compare.
Think I will get the install started tonight

Tim
PS after I have a drink long day a work and yes I am running a desktop

Jason
Running LinuxMint xfce 32bit with Rtai kernel
Setup as in post:

forum.linuxcnc.org/forum/9-installing-li...-help?start=80#66528

Also I waited as you suggested to install latency measures after linuxcnc was installed, it did cut down on time.

This is with grub parameters:

quiet splash lapic noxsave -original paramters- intel_idle.max_cstate=0 processor.max_cstate=0 isolcpus=1 acpi_irq_nobalance noirqbalance

When first starting latancy plot I get a spike that is the red b.max in screenshot pic of latancy plot same as 64 bit. I took screen shots just as large file write started and finished. As you can see while transfer was taking place CPU1 usage was 100%, CPU2 was not at full load much different than 64 bit system which CPU1 & 2 where both at full load during transfer of files. After transfer CPU1 is still carrying a modest load not over 90% unlike 64 bit system, CPU2 dropped to 0%. Latency stayed low during test, (below 10000us) for base latency had a few spikes on servo base but not bad. This was done with 4 instances of glxgears, Firefox open on wired connection, music playing in repeat mode, file manager open with large file write, (6.6GB) to hard drive same as on 64 system. I did also notice CPU1's load is much less than 64 bit system had during this short pretest run. I also reset histogram after starting like on 64 bit test to avoid program start spike.






Started Histogram it is now 4:30am will let run till about 1:45pm that will be about 9 hours. will update post afterwards with screen shot as before. Changed my mind ran test for 11 hours same as I did with 64 bit Rt kernel screen shots of test results below







Tim

Found my own answer with a little reading about histogram