HP DC7600 - Latency not as reported in the wiki

I recently bought a used HP DC7600 (Intel P4 3Ghz single core processor) off eBay as it is reported to give latency of 6430 using the on-board graphics: wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test

Despite disabling HyperThreading and power management in BIOS, this hardware produces 36K latency on a 3hr test using the Ubuntu 8.04 Live CD. A clean install of Debian Wheezy and a custom uni-processor kernel (thanks Arceye) produces around 25K on a short test and is clearly nowhere near the reported figures.

I'm currently questioning the authenticity of the wiki report. Can anyone with this hardware please tell me what numbers they are getting and/or suggest the optimum setup?

Hi

That's disappointing.

The entry does say that they used 10.04, disabled the kernel sound module and installed the smi fix.
The test was not exactly heavily loaded either (two instances glxgears)

However 25K sounds too low for a board with a SMI problem

Do a lspci -vv and then try to establish if these are spikes or general high figures using the realtime latency test in a terminal

regards

Yeah, VERY disappointing given all the hard work I've done over the last few months with 2 other PCs and still don't have any hardware capable of <15K latency.

Correct me if I am wrong, but I thought the SMI fix only applies to multi core CPUs? If so, I don't understand why the wiki reports that it was applied when the P4 3Ghz is a uni-processor? cat /proc/cpuinfo confirms that only one cpu is found.

I've disabled audio in BIOS and blacklisted all the snd_* modules, soundcore and pcspkr. I've dsabled unused services using rcconf - acpid, alsa-utils, anacron, atd, avahi-daemon, cron, exim4, kbd, motd, nfs-common and rsync, yet still get latency around 25K. I've also tried using software OpenGL but it makes unnoticeable difference. The graphics driver in use is the i915.

Ubuntu 10.04 Live CD gives around 45K latency, so I have not tried installing it.

Running the latency test in /usr/realtime/testsuite/user/latency goes straight to 4294967296 from the very first result and stays there?

Correct me if I am wrong, but I thought the SMI fix only applies to multi core CPUs?

You are possibly thinking of the isolcpus kernel parameter, which applies only to multi core

It applies to Intel chipsets, stands for System Management Interrupt (or similar).
There are probably more uni processors with affected chipsets than multi-core, just do a lspci -vv and compare the number and revision to the list on my FAQ to be sure
www.linuxcnc.org/index.php/english/forum...me-latency-solutions

Does not sound like the problem though

Beyond trying PS2 mouse and keyboard and one of your other video cards, might be time to put it back on Ebay

If you post the full latency test figures (the one in the dialog) I will edit the wiki and put a warning with those figures in it

regards

PS

I am loathe to recommend something, bit like recommending a restaurant to find the chef ran off with the owners wife and the food is now dire

If it is any use I have 3 of these

www.ebay.co.uk/itm/Fujitsu-Siemens-Sceni...&hash=item460e8b86f7
with a Matrox G550 video card similar to this
www.ebay.co.uk/itm/DUAL-MATROX-G550-32MB...&hash=item3cbcf4a05f

all running the Debian 7.1 3.5.7-rtai build sub 10K loaded

Thanks Arceye.

I'm determined to try everything I can to get this DC7600 running decent numbers before writing it off...

lspci -vv reveals that the chipset is 82801GB (which IIRC is the same chipset as my other HP mobo) so SMI is not the issue here.

I've gone through every BIOS setting, Googling those that I was unsure about and have disabled everything that may cause latency issues. Other than the usual power management, audio and HyperThreading settings, disabling "pci serr# generation" and setting "sata controller mode" to IDE seemed to make the biggest improvements.

Running the latency test from the realtime user testsuite will run 6.5K all day long with no load...with about 80% of the "lat max" numbers being <2K. With 10x glxgears, the overall max rises to 12.5K and approx 50% of the "lat max" numbers are <2K. Launching and closing IceWeasel (Firefox) about 10 times will push the overall latency to around 25K. This is with the on-board graphics. Testing with my PCI-E cards give a max overall latency of 20K (Radeon 5450) and 18K (Radeon X600) under heavy loading.

I've bought a Matrox G550 32Mb card and a DVI to VGA converter off eBay and will test when they arrive. I went for a standard PCI version as neither of my Intel boards has an AGP slot and I will also be able to test it on my AMD rig. Fingers crossed, the Matrox will give me some better results...

In conclusion, I think the Wiki is misleading, or at least not applicable to *ALL* HP 7600's. I can match the results with minimal loading but give the PC some work to do and the latency is more like 25K with the suggested hardware. Maybe the person who added the DC7600 entry to the wiki could confirm what numbers they get with real-world testing?

I'm a little confused...

Although the 82801GB is not specifically mentioned in the SMI fix wiki, lspci -vv DOES mention ICH7 Rev 1 which IS mentioned in the wiki. However, I don't think my hardware is suffering from the SMI issue because there are no obvious latency spikes at regular 32 sec or 64 sec intervals. As I said above, the latency test will run at 6.5K for 10+ minutes with no loading. Based on that, I'm assuming the SMI issue is not coming into play. Or is it?

Hi

Very confusingly, Intel began designating chipsets numerically AND by letter codes after the 82801E& code

82801GB should be the same as ICH7_1

You are not displaying classic SMI symptoms, but nothing lost by trying it, the module will only work if it detects the correct chipset

If there is an option to have the fan on full all the time, select that anyway to prevent temp checking interrupts and should prevent any overheating

regards

I think the Wiki is misleading, or at least not applicable to *ALL* HP 7600's. I can match the results with minimal loading but give the PC some work to do and the latency is more like 25K with the suggested hardware.

There are 2 issues at work here.

The first is that manufacturers keep a popular model going for a while, but change chipsets etc even though the model number remains the same.

The second is human nature. Having bought a computer, some people do not want look too hard at the figures or admit what they bought was not quite as good as they thought and give it best scenario gloss.

Because there is no 'standard' latency loading test, all the results are somewhat subjective.
Whilst I would never actually run a browser on a machine whilst it was cutting metal, it does simulate high disk access, network activity and loading a large program and can show up bottle-necks

Running the latency test from the realtime user testsuite will run 6.5K all day long with no load...with about 80% of the "lat max" numbers being <2K. With 10x glxgears, the overall max rises to 12.5K and approx 50% of the "lat max" numbers are <2K. Launching and closing IceWeasel (Firefox) about 10 times will push the overall latency to around 25K. This is with the on-board graphics. Testing with my PCI-E cards give a max overall latency of 20K (Radeon 5450) and 18K (Radeon X600) under heavy loading.

You seem to have been very thorough.

The most important spikes to my mind are those that occur when tabbing between windows, dragging windows around forcing repaints, generally moving the mouse.
These are strong indicators of graphics weakness that can often be 'cured' with a dedicated graphics card

The computers I highlighted worked fine with 8.04 with the onboard graphics chip returning +/- 9K
When I put Debian 7 on them with the 3.5.7 kernel the result was disappointing, about the 20-25K you saw. I was able to zero in on the graphics as the most likely source of the increased figures by the indicators above
and a humble 32MG AGP card returned the figures back down to 5K unloaded and 9K with a good loading

regards

Just to throw a bit of mud into these already muddy waters, the latency test is a bit unrealistic since it does no physical I/O. Physical I/O can be blocked for fair amounts of time by DMA or bus mastering devices. I noticed this on the Atom MBs that are so popular:
the latency test has some real nice numbers but if you toggle a parallel port bit in hal and look at the jitter with a oscilloscope its noticeably worse than the latency test would indicate.

If you are really obsessed with latency you might consider a hardware step
generator or a BeagleBone Black. Both effectively move the base thread to hardware
(well PRU firmware in a BBB case)

I think the main pitfall here IS the fact that HP will have manufactured the DC7600 series with different generations and versions of hardware. Hell, even PCs with the same hardware can produce different results due to electronic tolerances.

Sadly, the Ubuntu 8.04 Live CD (with the BIOS optimizations as stated above) gives latency of 38K with no loading, so I'm starting to think I've got another lemon.

Having read the SMI fix wiki, it's not clear how I should go about compiling it for a RIP environment on a custom kernel. The wiki is based on the out-dated Dapper and doesn't indicate how to compile on Wheezy or other OS's.

I've just read that using a Kernel with ACPI enabled can reduce SMI's, so I'm going to try a fresh install of Wheezy and use Seb's 3.4.55 kernel. Meanwhile, can someone please clarify how to compile the SMI module for this OS?

To be honest, I'm quite disappointed at how fussy realtime is on hardware. I've worked hard on 3 PC's and still don't have a workable solution. OK, 25K latency is probably usable but my milling machine has 5mm pitch ballscrews, 2:1 ratios and the steppers run smoothest at 1600 pulses...so 25K latency gives poor rapids.

I know nothing about hardware stepping - is that a solution that will run on ANY old PC that can run LinuxCNC?