dual cpus with seti

[snowyowl]

I am running two Celerons at 450. When running SETI, both of my processors work on the set. But they each work at 50%, so it ends up being basically the same as when I had one processor. In fact I think it is a little slower. I used to get 8.5 hours with one Celeron at 450. Now it is about 9.5 with the same chipset (440BX). So I created two seti folders and two separate clients. Then I set parameters in Seti Spy so that each set would use a different processor. Now each processor is being used 100% (as I see in the task manager), but the sets take about 12 hours to complete. This is much better than before because that is really 2 sets for every 12 hours (6 hours per set). However, why can't I get 9 hours a set like I did with one processor.

 

[BurntKooshie]

Because even though the clients are better now than they were before, they are still very memory bandwidth/latency bound. Because Intel uses a shared bus architecture, the CPU's have to effectively fight each other for bandwidth, so each one gets less. S@H is still a "diminishing returns" when it comes to modern CPU's.

If you had P3 Coppermines, or even P3 Katmai's, the situation would be a little bit better, because they have larger cache's which help alleviate the need for high main memory bandwidth. Celeron's just don't have enough cache to compete with its big brother, especially in multiprocessor based systems.

It's still nice to be able to run two clients though 😉

 

[Tbird]

i was getting average of 8.5 hours of my dual rig until client 3.03 times went to 13 hours


dual PII 450
Gigabyte 6BXD
4 maxtor 40g ideraid
1 quantum 8.5g
512mb ram
creative 3dblaster2
sblive!
intel pro10/100 nic

 

[Ken g6]

For bus-bound people doing SETI, I recommend running SETI on one processor and RC5 (or some other project) on the other. I know RC5 fits in the processor cache, so it won't conflict with SETI on the bus.

 

[Michael]

It is important to note that the SETI client is not naturally multithreaded. If you want to use both processors, you need to run two instances of the client and (depending on the OS), assign an instance to each processor.

Since SETI is still memory bandwidth intensive and almost all multi-processor arrangements share the same memory, you might have a slight slowdown, especially with Celerons which have less cache.

Michael

 

[Assimilator1]

Ken G6
That as it maybe ,but he will still get more SETI WU's using both CPU's on SETI.
I guess it depends on his interests 🙂

Micheal
Hehe ,he is running 2 instances 😉

 

[Poof]

Snowyowl - both your processors are fighting for that RAM to slap the seti stuff into. It's especially bad on the cellys 'cause their L2 is so small.

I run SETI on a dual Xeon (2 processes) and since my Xeons each have 1Mb L2 cache, they don't have to even run seti in the slower 100Mhz RAM... This was especially so with the 2.4 CLI, when the working set fell out of everyone else's cache onto the slower memory bus, but us Xeon owners... 😉

 

[dman]

OOps, misread your post. Correct responses above.