Dell Precision 390: Build log

Just sharing some of my experiences with a Dell Precision 390 that I picked up locally on Craigslist for 125$

Machine was originally running Win7 Ultimate/Gargantuan/Super/Hippie-Dippe x64

Hardware:
Intel Core2 Duo E6300 @ 1.86GHz
2GB RAM
ATi RV530 PCIe
160GB SATA

The goal is to run 4-axis of closed loop servo control using Pico's PWM board and their BLDC drivers on a Taig. (In case you're thinking it is overkill to run brushless servos on the Taig, I know that there are easier setups to get going, but I REALLY want to get a grasp on closed loop controllers as the projects I plan to tackle with my mill will be implementing them as well).

Installation attempt #1:
Install was with the current LinuxCNC 2.6 .iso which I first attempted using a bootable USB made on an Asus Eee PC netbook running Lubuntu using the dd instructions. This attempt failed, resulting in a boot of the 390 that never recognized the USB as bootable. This process was repeated at least 2 more times to ensure I was correctly performing the format process.

Installation attempt #2:
Burned a DVD of the .iso on a Windows machine, since DVD-RW on the 390 konked out. Installation from the windows generated DVD worked perfectly.

Configured BIOS settings to disable power savings and unused resources (at the time this included audio and network). Ran the latency test with no isolcpus and was getting spikes of the servo thread of at least 100us on a non-periodic basis, i.e not likely SMI. CPU(s) would be at 100% running 15 HD MPEGs. Peaks occurred most often when opening the MPEG files so attributed some of this to disk access.

Then ran then with isolcpus (tried both 0 and 1) and saw a drop in the average latency (<10us), but the same spikes were seen of at least 100us. Was beginning to think I'd found a nice door stop.


Installation attempt #3:
Received some advice from user PCW to try my hand at preempt as he thought that I might see better results, sharing histograms from a few machines he'd tested with latencies averaging ~20uS with an E8500 similar CPU (more GHz and larger cache than mine). Not knowing what preempt was when first suggested, it took me a few evenings of piddling around before getting lucky and finding a way to get it to work. All installations are now made from DVDs burned in Windows as it has been the only method I've been able to get to work thus far. Installed Wheezy 7.8 x64 and then added the key and repos for the preempt branch and used Synaptic to install.

Now getting peak latencies of no more than 50uS. There are a few residual problems that I am still working through:

1) Display will momentarily blackout on a random basis. The PC is in my garage and it's been pretty hot in North Central Florida these days so not sure if I have driver issues or if something is overheating? Haven't been able to identify if it happens in cooler ambient temps. I tried the proprietary ATi driver and got a black screen so went back to the xserver radeon driver.

2) Running the histogram latency test only allows me to open no more than 4 instances of Glxgears before no longer opening new instances. The system does not allow opening of other applications at this time either, CPU is at 100% so guessing it's working as hard and as fast as it can, and can't get to other threads. Latency is holding under 50uS in these testswith an average of 20uS.

Need to update the latencies page with this setup for the 390 that I already posted after the attempt # 2 configuration.


CPU Upgrades:
In order to further experiment with latency reduction (and to make this computer usable for more than just running a mill, possibly run FreeCAD), I splurged on two used 775 socket CPUs specifically an E8400 and Q9950. (Less than 75$ total for them)

Tested each but nothing happened on bootup other than loud fans. Did a little research and learned that BIOS update may be required. It was running a 2.6.0 BIOS version, but there are apparently multiple 2.6.0? The first released in '08, but maintained through '11 while still retaining the 2.6.0 version...go figure. Finally got the BIOS to update which didn't magically bring either of the CPUs to life.

Lesson learned: Check your FSB specs before purchasing! There are multiple variations of the Dell motherboard that the 390 comes with. My version (0DN075-70821-73K-50AX) is limited to 1066MHz, and the E8400 and Q9950 are 1333MHz FSB CPUs. Now need to look for a Q6600 or Q6700 to test with which have the right FSB frequency, but could still contain more opportunities for learning...

More lessons to come!

The link to the previous topic in Drivers Boards that I started all of this in is here: www.linuxcnc.org/index.php/english/forum...uction-and-new-build

After debugging the problem with the limit on Glxgears, I came across this message in dmesg:

...
[drm] Loading R200 Microcode
platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin
radeon_cp: Failed to load firmware "radeon/R200_cp.bin"
[drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
...

which led to a solution regarding firmware for the xserver for radeon:

$ apt-get install firmware-linux
$ dpkg -L firmware-linux | grep R200_cp.bin

which got rid of the error in dmesg, but it has ruined my latency! Now experiencing 200uS+ peaks. Really hoped that eliminating GPU problems would help latency, not work against it....perhaps I've created more. Good news? is that I can now run as many copies of Glxgears as I want. If only watching parallel copies of that animation were as fun as actually making things on a mill!

Tried isolcpus again to see if it would bring back any performance, but no luck. Histogram attached.

Well I performed a few more experiments

1) Removed the installed firmware to see if I could regain the previous performance. Easy enough return to around a 42us peak.

2) Realized that it was possible that I'd installed the incorrect driver for the GPU. So went back through the firmware process installation (confident now that I can always revert) for what I knew to be for the correct model/family of board RV560. Installed, and returned to somewhat better latencies than the previous installation, but still above 100us.

3) Started to dig into when the latency was being generated: Glxgears generation, HD Youtube video, network access in general? It turns out that the Chromium browser I was using was the trigger for the 100us spikes. Dumped it and went back to Iceweasel and have now been able to run with a max of 39us! While running 25 Glxgears.

Lesson learned: Chromium is a resource hog!

It turns out that the Chromium browser I was using was the trigger for the 100us spikes.Chromium is a resource hog!

Now I have a reason beyond prejudice not to use Chrome

Google has become all pervasive and as big a danger to computing as Microsoft ever was.

Their innovation was good, but it is all about money now, with corporate shareholders demanding returns.

Plus a management with egos the size of planets who think they can do anything and just buy up anybody who might have had a better idea first.

Don't get too hung up on latency testing, if you are not using software step generation off a base thread, anything under 100us will probably work, certainly 50us
Glxgears is supposed to try to simulate openGL in the gremlin widget of Axis, but 25 instances whilst watching a flash video is not real world testing

regards

Extended testing has indicated that Chromium wasn't to blame. Iceweasel developed the same problem but took longer to develop. I also identified the screensaver as another latency generator. So all in all, it seems to be triggered by graphical rendering tasks. This would seem to go against the thinking that external GPUs would offload processing required for graphics and subsequently decrease CPU load. Testing indicates that CPU is loaded more by a GPU with high throughput. So best case for my current hardware is to break the GPU driver so it asks less of the CPU.