I have read a couple posts regarding Multi-core processors, but my question wasn't answered.

I just updated SETI to the latest version to get rid of the blocked program under UAC in Vista. I noticed while playing an online game that my FPS was really crappy, which has not been the case since I built this machine. I have a quad core processor and was running SETI on 3 of them.

I just happened to mouse over SETI and saw 4 tasks running. Imagine my surprise. So I went into SETI and sure enough there are 4 tasks running. I double checked my settings and noticed that % of processor speed is default instead of the # of processors I want to use.

So here is my question, if I set % of processor speed used from 100% to 75% is that the same as the previous version of choosing the # of processors? If that doesn't make any sense, then how about saying it this way: I assume that on a quad core processor, 100% = 4 cores are running. If that is the case then I should set it to 75% so that only 3 cores are running.

Am I up in the night smoking something or is this the way it works!?!?!?

Thank you :-)

---

I reject your reality and substitute my own

boincstats.com

where did you set this and is your computer given a local settings
if you using the websites settings then you need to tell boinc that

I have read a couple posts regarding Multi-core processors, but my question wasn't answered.

I just updated SETI to the latest version to get rid of the blocked program under UAC in Vista. I noticed while playing an online game that my FPS was really crappy, which has not been the case since I built this machine. I have a quad core processor and was running SETI on 3 of them.

I just happened to mouse over SETI and saw 4 tasks running. Imagine my surprise. So I went into SETI and sure enough there are 4 tasks running. I double checked my settings and noticed that % of processor speed is default instead of the # of processors I want to use.

So here is my question, if I set % of processor speed used from 100% to 75% is that the same as the previous version of choosing the # of processors? If that doesn't make any sense, then how about saying it this way: I assume that on a quad core processor, 100% = 4 cores are running. If that is the case then I should set it to 75% so that only 3 cores are running.

Am I up in the night smoking something or is this the way it works!?!?!?

Thank you :-)

No....that's not how it works.....
The % of processor speed used will vary the duty cycle on whatever number of tasks are running so that the cpu time used averages out to the percentage you have set....
You have the option in your preferences to set the number of processors used...if you set it to 3, then Boinc should only run on 3 cores, leaving the 4th one unused.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

The crappy performance can also be a Vista thing and SP1 seems to solve some of it.
Before I installed SP1 on my Q6600 I had to stop BOINC if I wanted to use Media Center and after SP1 it works fine and BOINC no longer has any impact on the performance.

---

Seti@Netherlands website

No....that's not how it works.....
The % of processor speed used will vary the duty cycle on whatever number of tasks are running so that the cpu time used averages out to the percentage you have set....
You have the option in your preferences to set the number of processors used...if you set it to 3, then Boinc should only run on 3 cores, leaving the 4th one unused.

partially wrong only applies to older Boinc version.

Use at most
(Can be used to reduce CPU heat)
Enforced by version 5.6+ 100.0 percent of CPU time
^Not recommended for use on multiprocessors - set to 100%^

On multiprocessors, use at most
Enforced by version 5.10 and earlier 3 processors

On multiprocessors, use at most
Enforced by version 6.1+ 75.0 % of the processors

As per the SETI preferences page,
"On multiprocessors, use at most 3 processors
(Enforced by version 5.10 and earlier)
On multiprocessors, use at most 75% of the processors
(Enforced by version 6.1+)"

So if you have the latest version of SETI, set number isn't enforced, % of processor use is.

As for Vista and SP1, I didn't install Vista until SP1 came out. BUT I know that isn't the issue because I have been running SETI on Vista SP1 since it came out.

SETI has been running great, Quad core processor is awesome and minus Astropulse, I still love SETI.

Thank you for the information, I'll keep it set at 75% of processor speed.

---

I reject your reality and substitute my own

boincstats.com

As per the SETI preferences page,
"On multiprocessors, use at most 3 processors
(Enforced by version 5.10 and earlier)
On multiprocessors, use at most 75% of the processors
(Enforced by version 6.1+)"

So if you have the latest version of SETI, set number isn't enforced, % of processor use is.

As for Vista and SP1, I didn't install Vista until SP1 came out. BUT I know that isn't the issue because I have been running SETI on Vista SP1 since it came out.

SETI has been running great, Quad core processor is awesome and minus Astropulse, I still love SETI.

Thank you for the information, I'll keep it set at 75% of processor speed.

Just so it's clear, there are two different settings:

A: Use % of # of processors
B: Use % of CPU time

For Multicore/multiprocessor machines, if you see a slowdown, it's recommended to set A to less than 100%. That frees up a core to allow other things to run.

If you set B to less than 100%, you are telling BOINC to pause frequently on EVERY core to get an average CPU utilization of say, 75%. So, you'll run as many WU's as you have cores, but at less than full speed.

As an example, I was seeing heat/shutdown problems with my laptop, which has a dual-core AMD processor. It works much better, and with less stress on the fan/CPU to set A to 50%, so it only runs one WU at a time, on one of the cores. I did try to just set B to 80%. It did run 2 WU's but it didn't seem to run as well.

---

Mark

the funny thing is that there is no guarantee that the online FPS game you play will lock onto the free CPU core. I don't know why Seti is running while you are in play but it shouldn't interfere with other programs that are running.

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

the funny thing is that there is no guarantee that the online FPS game you play will lock onto the free CPU core. I don't know why Seti is running while you are in play but it shouldn't interfere with other programs that are running.

What I have found, and this has been noted once before a few months ago, that the core/CPU utilization is different on Windows than Linux. If you have a quad-core CPU running Windows, and a single-threaded app runs, it runs evenly on all four cores. At the same time, if you have 4 WUs crunching, they balance evenly on the four cores, constantly switching from one core to another.

With Linux on a quad-core CPU, a single-threaded app will run on the same core until it is interrupted or exits.

So for Windows, if you have a quad and you set it to only run on 3 cores, you'll end up with the task manager saying you have an average utilization of.. 75%, but if you look at the graphs, you don't have 3 maxed out and one completely idle, they'll all be at about 75%, with some up and down spikes on each. This can be solved on a very short, temporary basis by picking your three tasks in the processes tab and manually assigning affinity to each WU, but as soon as one finishes and a new one starts, the new one will be set to all the cores, so it will start core-hopping again.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

This can be solved on a very short, temporary basis

The appropriate question is "what problem do you think you are solving this way?"

I think most of us who have run checks have not found an execution throughput benefit to asserting core affinity for SETI. Doing so in spite of that finding is removing a degree of freedom in scheduling, which will probably cause some actual harm in some circumstance.

---

This can be solved on a very short, temporary basis

The appropriate question is "what problem do you think you are solving this way?"

I think most of us who have run checks have not found an execution throughput benefit to asserting core affinity for SETI. Doing so in spite of that finding is removing a degree of freedom in scheduling, which will probably cause some actual harm in some circumstance.

I wasn't saying it would perform any better, just stating that if you wanted there to be an "idle core" like keeps getting mentioned, manually assigning affinity to processes would be the only way to truly achieve one idle core. Letting them hop around from core to core involves having to transfer data from one L1/L2 cache to another on a constant basis, and ends up giving you the equivalent of one idle core, but the reality is that all four are roughly evenly loaded, as well as evenly idle.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I've seen on occasion times when my single core has multiple tasks running. I've track this down to times when I get a few really short deadline workunits. As each are downloaded, each one jumps to the front of the queue and start a client task, stopping the previous one but the previous one doesn't unload from memory (yes I have it set to do that).

Times when I catch it doing that I simply shut BOINC down and restart it which then only starts up one client.

---

"Life is just nature's way of keeping meat fresh." - The Doctor

I've seen on occasion times when my single core has multiple tasks running. I've track this down to times when I get a few really short deadline workunits. As each are downloaded, each one jumps to the front of the queue and start a client task, stopping the previous one but the previous one doesn't unload from memory (yes I have it set to do that).

Times when I catch it doing that I simply shut BOINC down and restart it which then only starts up one client.

That's not a problem......
You probably have your preferences set to leave suspended tasks in memory....
So when your client goes into EDF and suspends processing a WU to do another one that it thinks needs to be done earlier, the suspended WU will stay in memory.

If you check your task manager (or equivalent in Linux), you should see your CPU only actually running the correct number of tasks....the rest should just be in memory waiting to run when the others are finished....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I've seen on occasion times when my single core has multiple tasks running. I've track this down to times when I get a few really short deadline workunits. As each are downloaded, each one jumps to the front of the queue and start a client task, stopping the previous one but the previous one doesn't unload from memory (yes I have it set to do that).

Times when I catch it doing that I simply shut BOINC down and restart it which then only starts up one client.

By design, BOINC doesn't unload a task if it has not done a checkpoint. There are projects which don't checkpoint at all so must be kept in memory even if the preferences say otherwise, but the logic also applies to S@H during the short time between startup and the first checkpoint. However, such tasks should be shown as suspended rather than running.

                                                                 Joe