This is in the context of having enough CPU's available to keep your GPU(s) running at full tilt.

And how do you "free 2 CPU cores" without making it so Bonic/Seti can't use them at all?

Thanks,

Tom

---

A proud member of the OFA (Old Farts Association).

@ Tom Miller:
There are at least 3 methods to keep "free cores":
BOINC Manager Options > Computing Preferences > Computing > Use at most xxx% of the CPUs
This will never let BOINC use more than the percent of the CPUs (not CPU time) specified.

Create an "App_info.xml" file and specify a limit.

Create an "App_config.xml" to specify how much each task-type uses, and the maximum allowed to run at a time.

These last 2 give greater flexibility, and I use the last one such as:
<app_config>
<app>
<name>setiathome_v8</name>
<max_concurrent>6</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.34</cpu_usage>
</gpu_versions>
</app>
</app_config>

This tells the Manager each V8 task will use 0.34 of a CPU and 0.5 of a GPU, with a maximum of 6 at a time. Thus a maximum of 2 CPU (6*0.34) and 3 GPU (6*0.5) units will be busy. The Manager rounds down to compute the numbers of units to allocate.

Of the above examples, only the first will free the CPU cores completely so they only cater for the GPU (plus anything else that runs in the operating system). The idea behind freeing cores for the GPU is that when you run work on all the CPU cores plus the GPUs, that the latter will slow down and possibly deliver erroneous work because you're fighting to have the CPU do work simultaneously with sending large data chunks to the GPU.

Work being done on the GPU doesn't mean that the whole application you see in Windows Task Manager runs solely on the GPU, that isn't possible yet with today's software hierarchy. A GPU application runs on the CPU, which in turn takes a task, divides it into chunks, translates such a chunk to the language the GPU can work with, transports it to the GPU, then waits for the GPU to finish completing the calculations, before transporting the data back, translating it back into human-readable form and storing it on disk. So, as you can see, quite a bit of the work done is done by the CPU. On some projects even more, as there certain calculations are also done on the CPU.

This means that for these GPU applications you want to have an as free as possible CPU core. Just so it's able to do the above uninterrupted.

---

@ Ageless:
Actually the phrase "free 2 CPU cores running multiple instances" literally means "do not run so much other stuff that more than N-2 CPUs are busy".

Given the number of cores high-end processors have, even letting ALL cores run other stuff is pretty good when the tasks supporting the GPUs are run at a higher priority with "-use_sleep". The more cores a processors has, the shorter the time, on average, before one of them will end their time slice and the support task(s) will be dispatched. Not using the sleep option does give a shorter elapsed time, at the expense of much more CPU usage.

I run most of my GPUs for SETI (at high priority) but give most of the CPU time (at idle priority) to other projects that do not have (or can not use) a GPU version to crunch. Thus I feel I am contributing more to science overall by not wasting the CPU time (and electricity) in that spin-loop. Everyone has their own opinions and choices to make, and these are mine.

Actually the phrase "free 2 CPU cores running multiple instances" literally means "do not run so much other stuff that more than N-2 CPUs are busy".

You didn't make it any clearer, more like worse to understand what you meant.

In any case, when one frees two CPU cores via preferences, these cores are used by the GPU and because they have no load, by anything the operating system is doing at the time. It's better to use it like that than to have to fight for position on the CPU core between the OS applications at normal priority, a CPU application running at low priority and the GPU application running at below normal priority. Just because these three fighting for the CPU will definitely slow down work done on the GPU, because it cannot be updated as quickly as it can be when it's not doing anything.

Given the number of cores high-end processors have, even letting ALL cores run other stuff is pretty good when the tasks supporting the GPUs are run at a higher priority with "-use_sleep".

You're now using an advanced option, one that's so badly documented that a normal user, using normal stock applications cannot find it. Well, maybe now when he does a search and finds the post I made about it (and the other command line options).

And even then, Results in additional Sleep() calls to yield CPU to other processes tells me that it slows down the application you specified this for. Yield = give way to other things. So don't run the application you set the option for, for so many seconds and only allow the CPU to do work on other processes, be it Seti CPU tasks, other project CPU tasks and non-BOINC CPU tasks.

At the end of the sleep period, it's back to 'one for all and all for one' - fight for your right to use the CPU core.

---

@Ageless:

In any case, when one frees two CPU cores via preferences, these cores are used by the GPU and because they have no load, by anything the operating system is doing at the time.

I think you are mistaken or confused about the use of the "Preferences", "Use at most...% of the CPU" field. This tells BOINC to use only this % of the CPUs and leave the rest alone. It does not physically isolate the CPUs for BOINC use. All CPUs are up for grabs by the O/S scheduler. Idle CPUs are preferentially used to dispatch newly ready work but even those SETI GPU tasks in a spin loop can have their use of the CPU taken at the end of their time slice if there is another ready task at the same priority. If a higher priority task comes ready, the O/S scheduler might even preempt a SETI GPU task from its spin loop. And of course, hardware interrupts can preempt any user task.

It's better to use it like that than to have to fight for position on the CPU core between the OS applications at normal priority, a CPU application running at low priority and the GPU application running at below normal priority.

Your use of "better" here indicates your choice to sacrifice CPU time for elapsed time. I respect your choice. I chose to use the "spin loop" CPU time for other science projects. Also, I used "higher priority" for SETI GPU work, which is dispatched before any work at a lower priority. The SETI GPU application is well behaved and uses small amounts of CPU to support the GPU and so does not impact my interactive use of the computer. Therefore, I assign it "High" priority, the highest priority below "real time". This is my choice.

You're now using an advanced option, one that's so badly documented that a normal user, using normal stock applications cannot find it.

I think you are underestimating what a "normal" user can do. I think my only abnormality is a willingness to do the research to maximize my computer resources and electricity usage for the good of science. I also think many other normal people do this, especially those who come to the forum to ask questions. Also, I am using stock applications to do it.

And even then, Results in additional Sleep() calls to yield CPU to other processes tells me that it slows down the application you specified this for. Yield = give way to other things.

I agree that the elapsed time will elongate some by using a "wait" timer instead of a spin loop. I also use other parameters to minimize the wait times. Please remember that the elongated time does not represent wasted time: it is used by other science projects or even SETI if you run the CPU versions as well as the GPU version.

You're now using an advanced option, one that's so badly documented that a normal user, using normal stock applications cannot find it.

I think you are underestimating what a "normal" user can do. I think my only abnormality is a willingness to do the research to maximize my computer resources and electricity usage for the good of science. I also think many other normal people do this, especially those who come to the forum to ask questions. Also, I am using stock applications to do it.

This reads like you misunderstood Ageless and are becoming defensive in your position. If you're using an advanced option, that automatically disqualifies you as a "normal" user. From my reading, it sounds like you're taking the mantle of "normal" as if Ageless meant to put down your choices when rather it is the opposite, I think.

@OzzFan:
Perhaps you are right:

@Ageless:
I apologize if I have given you any offense.

Gulp. Let me see if I got the heart of the discussion here (obw, I am clearly more normal than anyone else here ;) <wink>

1) Am I understanding it that using the "sleep" option decreases the absolute "speed" with which a gpu will process the same work unit?
I think I do get, that by doing that you make the cpu available to do other non-gpu processing?

2) So, if you want the lowest times to process a GPU work unit, you don't want to use the "sleep" option?

3) But if you want to increase the resources available for CPU-based number crunching while continuing to make respectable process on the GPU side then the "sleep" option beckons?

Thanks,
Tom

---

A proud member of the OFA (Old Farts Association).

This is from the README file in the project folder:

-use_sleep :Results in additional Sleep() calls to yield CPU to other processes. Can affect performance. Experimentation required.

-use_sleep_ex N: enables use_sleep; sets argument of Sleep() call to N: Sleep(N)

Here is a more detailed explanation.  Scroll to the third entry.