• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

SMP, Umm

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

jstutman

Member
Joined
Oct 13, 2001
:confused:

How long does it normally take to complete an SMP WU?

e6300, and e6400 are moving like molasses.
what like 3 days, its at 13%

\/ this one is from the 6300

Code:
[09:02:31] Completed 22610 out of 500000 steps  (4 percent)
[09:02:35] Extra SSE boost OK.
[10:46:00] Writing local files
[10:46:00] Completed 25000 out of 500000 steps  (5 percent)
[14:50:01] Writing local files
[14:50:01] Completed 30000 out of 500000 steps  (6 percent)
[18:55:20] Writing local files
[18:55:20] Completed 35000 out of 500000 steps  (7 percent)
[23:06:59] Writing local files
[23:06:59] Completed 40000 out of 500000 steps  (8 percent)
[03:23:23] Writing local files
[03:23:23] Completed 45000 out of 500000 steps  (9 percent)
[08:17:34] Writing local files
[08:17:34] Completed 50000 out of 500000 steps  (10 percent)
[12:42:34] Writing local files
[12:42:34] Completed 55000 out of 500000 steps  (11 percent)
[16:52:46] Writing local files
[16:52:46] Completed 60000 out of 500000 steps  (12 percent)
 
Are there any other programs or processes that might be running in the background interfering with it? How about a screensaver? They also seem to take up quite a lot of CPU cycles. If it isn't one of those things, the SMP experts should be along soon to help you out.
 
No current WUs are that slow. You will not make the deadline on that work unit and are currently wasting your time.

What WU?
What OS? If windows, look for runaway processes.
What speed is the E6300 running?
C1E enabled or disabled?
Speed Step enabled or disabled?

Allendales make from about 260 ppd/Ghz (00:32:00/frame @ 2.4 GHz) on the worst WUs to 635 ppd/GHz on the best.
 
Last edited:
running 724 with a decent oc and fairly fast memory 6300/6400 should be able to complete any smp wu in less than 2 days.

additional questions ... how much memory, what speed?

Also, although it supposed to be forced on by the smp client, i always run with -forceasm.

I have noticed on a wxp rig that firefox can consume a lot of cycles sometimes if i leave it running with a lot of windows/tabs open.
 
You should be using the -verbosity 9 flag in your startup script so that the client will write timered checkpoints to the log. If you see a bunch of timered checkpoints between frames, you immediately know something is wrong, without doing any math. This assumes you set checkpoints to 15 minutes or even better 30 minutes and not something ridiculous like 3 minutes.
 
How long does it normally take to complete an SMP WU?
Your Time per frame should be in the 30 to 40 min range (at worst) with stock speeds. They should be much faster then that more like 24min or less with OC's.

Go staright to your Bios settings and do not pass go...repeat straight to your energy saving Bios settings.
 
Vista 32 bit, Ultimate

minimal processes running, until I run Client, with both cores at 100%

This rig has 3 gigs of ram, the e6300.

They both appear to have this WU

Current Work Unit
-----------------
Name: Protein in POPC
Tag: -
Download time: August 13 06:37:39
Due time: August 17 06:37:39
Progress: 12% [|_________]

K, the only thing I see is that I started the core, around 3 days ago, yet it says "downloaded August 13"

I normally run the non smp version, which completes on time and expected PPD. The non smp has 2 folders for core1 and core 2? Should the SMP be the same? It has 2 FAHlog's labled 1 and 2. However 2 is empty.

Even wierder.... 4 I repeat 4 instances of fahCore_a1.exe's are running.
(ponders, did it somehow install itself as a service and since im running the window, it is running twice?) <-----Think that may be the issue :)

Edit: guess not, closing the window, cancels all 4 processes, leaving zero CPU usage.....

and even when I close the client, MPIEXEC.exe still runs (25%) csrss.exe is at 0% (google tells me these are Folding@home related)
 
Last edited:
You've got a p2653 which is a high production WU on a 2MB C2D. You can expect 635 ppd/GHz (about 00:14:40/frame @ 2.4 GHz) if the machine is running right. THe SMP client spawns 4 cores which should each be showing about 25% cpu in task manager. If that is the case, then I'd run cpu-z and see just what the machine is clocked at, cpu and ram. With Speed Step enabled, and FAH set at idle priority, it may be taking the multiplier down to minimum.
 
THe SMP client spawns 4 cores which should each be showing about 25% cpu in task manager.
My memory must be failing me I only remember 2 cores running on a dual core. Each at less then 50%

EDIT: I'll bet it was because I was running it in VMware.
 
Last edited:
dfonda said:
My memory must be failing me I only remember 2 cores running on a dual core. Each at less then 50%

EDIT: I'll bet it was because I was running it in VMware.

I just checked my VMware and, as I remember, it's four cores. fahCore_a1.exe, four of them. The percentages are extremely bizzare, but there's four of them at least. If I remember right, the SMP clients are hardcoded for four threads.

I wonder about the thread count though. Is four threads only the hardcoded minimum? Will it spawn more if there's more processors, like in an 8 core box? Seems pretty bizzare to do otherwise.
 
ATM, it's hardcoded @ 4. In the future, I think we can expect to see 2 core and 8 core and perhaps more cores with the SMP client..
 
ChasR said:
ATM, it's hardcoded @ 4. In the future, I think we can expect to see 2 core and 8 core and perhaps more cores with the SMP client..

So the other four cores on an eight core box are squandered with one client? You need to run two?
 
ChasR said:
Run two. Some of the higher bandwidth WUs prevent linear scaling of production.

Have you made some kind of grand list/chart of work units that don't go well together? On system 1 as noted in my sig, I noticed that a pair of 2653s lose about 50ppd each, as opposed to being run alone, such as when one vmware instance finishes and is doing its end of unit stuff. In contrast to, I think, a 2610 and a 2653, where each lost 100ppd or more. It would be useful to know which units were more intensive on which parts of the system - cache, memory, bandwidth, etc.
 
P2608, p2609, and p2610 are high bandwidth, cache intensive WUs. Running two of them together should cause a quad to make less ppd than if it ran one.
 
ChasR said:
P2608, p2609, and p2610 are high bandwidth, cache intensive WUs. Running two of them together should cause a quad to make less ppd than if it ran one.

Confirmed in linux ... 2 instances of any of those 3 wu types together will result in lower total production.

All observations in linux - I have not tested 2 instances on the quads in native or vmware under wxp.

Mix in a 2651/3 with any one of 2608/9 and production is a bit higher (10%?) than running 1 instance. I think the same is true with 2610 but limited observations or that mix.

Run 2 2651/53 together and production is 20-25% higher than 1 instance.

I expect 2652 behaves like 2651/3 but i don't get many of them so I haven't really noted their effect.

While running 2 instances is not generally recommended, with an oc'ed quad @ ~3.0 ghz, 2 instances of compatible wu's still complete in < 1 day so the impact on the science is not too great. However, getting the wrong mix and not being able to move wu's to another instance, or run them serially, does impact things which is why it is not recommended to run 2 instances without close monitoriing.
 
Last edited:
pscout said:
All observations in linux - I have not tested 2 instances on the quads in native or vmware under wxp.

I'm running a Q6600 at 3.2GHz in VMware Ubuntu with XP as the host. Two virtual machines each with 2 cores.

pscout said:
While running 2 instances is not generally recommended, with an oc'ed quad @ ~3.0 ghz, 2 instances of compatible wu's still complete in < 1 day so the impact on the science is not too great. However, getting the wrong mix and not being able to move wu's to another instance, or run them sially, does impact things which is why it is not recommended to run 2 instances without close monitoriing.

Since this is on my main box, I'm not going native Linux. But so far the units are completing in only 1-2 hours more time than when I was running the E6600 as my main. Each one completes in 18-20 hours. So, not bad. At the moment I have a pair of 2653s on my quad and they are both getting about 2160ppd, which went up to about 2190ppd each when I've been away from my box throughout the day. 8*401 = 3208MHz, 800MHz DDR2 at 4-4-4-12 2T.
 
Sorin,
On the P5B, do you have 401 FSB set in bios or is that what cpu-z reports? I ask because the change to 1333 strapping occurs at 401 FSB and ram bandwidth takes a 10% hit compared to 400 FSB. THe 8 Mhz increase won't make up for it.
 
ChasR said:
Sorin,
On the P5B, do you have 401 FSB set in bios or is that what cpu-z reports? I ask because the change to 1333 strapping occurs at 401 FSB and ram bandwidth takes a 10% hit compared to 400 FSB. THe 8 Mhz increase won't make up for it.

401 is set in BIOS. I tried 400, and that was my preference, but it was WILDLY unstable, regardless of voltage even up to 1.5v. Blue screens, no posts, etc. I put it to 401, and it was completely stable at 1.4v. I know about the strap change at 401 and the performance drop that comes with it. This really bums me out, but, I did what I could. I also tried 425MHz, to help get some bandwidth back and some more overall frequency, but it wasn't stable at 1.45v and it was getting a little too hot. Maybe I'll do some lapping someday, but this where I'll sit for now.

I was going to get a quad at the price drop in July regardless of stepping, since when I first heard of the price drop, I just couldn't resist. G0 was just icing. Unfortunately, it's not doing as well as I'd hoped. I guess part of the blame is my lamely high VID, which is 1.3125v. Very disheartening, especially when I'm seeing most people around 1.25v VID or less.

It's odd though, my E6600 was perfectly happy using the 400 bus and this is all exactly the same hardware, just the CPU swap.
 
Back