Does affinity help SETI?

[sheridan]

I have a couple of machines with dual PIIIs and Win2K, both Pro and server. Each runs two instances of the SETI command line program, v3.08.

Whenever I remember after a reboot, I set the affinity so that one SETI runs on CPU0 and the other on CPU1. This is just because I feel instinctively that this should cut down on the task switching and might add a few % or fractions of a % to the overall efficiency of the two tasks.

Does anyone know if I'm right or just kidding myself?

I know I could set up a test with the identical SETI units running with 'single' affinity or the default of using both but I suspect the only way to do this 'realistically' would be to also run a few other tasks as well and this would need to be repeatable for both tests. Since I do actually have a life as well, I'm not inclined to go that far but I wonder if anyone has some test data on this subject or even some intelligent guesswork.

If you’re still with me, I also have a single P4 3.06Ghz box with hyperthreading. W2K Pro likes this as a dual processor machine and I do the same 'single' affinity setting with this running two instances of SETI command line v3.08. So.... is the affinity setting doing me any good on this setup?

Just for clarification, all systems do run other programs as well, but over 24hrs it's probably only 10% utilisation on all the non-SETI work. I don't mess with the affinity of any other task so assume they all use the default affinity of both processors.

Thanks in anticipation for your interest and help.

[Rattledagger]

There's no reason to manually set the affinity in task manager for seti, since this is part of the client.
Just start the 1st with -cpu 0 as part of the start-line, and the second as -cpu 1

[sheridan]

Thanks, that's useful info but.... does it help performance?

[High_Jumbllama]

It would ensure that is maximized as in this case both clients would never be on the same CPU.

[sheridan]

Hmmm... I can see that but surely they would only both run on the same CPU if another task or tasks were running on the other CPU.

As soon as other tasks enter the picture, it’s a matter of how the OS allocates resources to each task. SETI is set as a low priority task by default (and seriously degrades performance for other tasks on my PCs if set higher) so it will take a substantial hit when any higher priority process runs. How much of a hit, I don't have the slightest idea!

There are too many things I don't know to even begin to really assess this. It's even more complicated as one dual P3 has 'S' processors with 512K cache, the other has 'standard' P3s with 256K. I understand and indeed would expect, SETI works better with 512K but when considering the P4, the total cache is 512K 'shared' (as are most of the internal registers) by two 'virtual' processors. With low level OS tasks running, the full 512K is unlikely to be available but it's surely reasonable to assume a lot more would be available (without flushing/refilling) to a single instance of SETI than running two instances. So, would a single SETI process more units with hyperthreading turned off and more cache available?

My own *very crude* tests lead be to believe I get about 40% more throughput running two instances with hyperthreading enabled compared to one instance and hyperthreading off - so that's what I do. Intel should use this as a benchmark!

Still don't know though if setting the affinity makes any difference, good or bad. Any real test data out there?

[Rattledagger]

I don't think I've ever benchmarked this, but I've used it since the v2.04-days. Like running as service, the gain was probably like a minute per... maybe it was 8 hours the machine used on v2.04...

S-processor? Well, I've got a machine with "standard" p3-processors, and these is 512 K cache... and the fastest this mainboard can take, 600 MHz.

I don't remember exactly the times any longer, but I think there's possible to set up a table looking something like this:
256 K cache compared to 512 K cache: 10% longer crunch-time
smp-penalty:
1 M cache: 0%
AMD: 5-10%
512 K cache: 10%
256 K cache: 20%
128 K cache: 40%
Of course, the machines must have the same front-side-bus & cpu-speed to be directly compared.

In other words, a dual 512 K cache-machine will produce 82% more than a single 512 K machine. A dual 512 K machine will produce 20% more than a dual 256 K machine, and a dual 256 K machine will produce only 51% more than a single 512 K machine...
Hyperthreading giving 40% is a bit lower, but still a good boost.

O, and if we suppose 20% penalty for 128 K, a dual 128 K-cached machine will only produce 8% more than a single 512K-machine...

[sheridan]

Thanks for that very interesting information.

Sorry I wasn't clearer regarding the PIII cache. It was sometimes difficult to keep up with Intel and the versions and varieties of PIIIs, their cache speed and size.

As I recall, early (Slot 1) versions had 512K running at half the processor (not bus) speed. (I've very fond memories of a Supermicro motherbord, BX chipset and 500MHz PIII which I still swear performed better than the 733Mhz PIII on the Asus motherboard it was replaced by).

That dropped to 256K running at full CPU speed (Advanced Transfer Cache?) around the time they moved to socket rather than slot.

The 'end of the line' PIIIs, mainly socket versions with 133MHz bus, ran the cache at full CPU speed and had 256K in what I described as 'standard' and 512K in the 'S' (Server?) version.

And thats not to mention Xeons....

Thanks again for your input. Guess it just goes to show that the eternal quest for knowledge is just that - neverending!