what should I do with SWAN_SYNC=0?

Create an environment variable called "SWAN_SYNC" and set it to 0 to get maximum GPU utilization. I have no idea how to do this in Linux, though.

MrS

I got SWAN_SYNC=0 set up on my Linux with a 6.08 WU, it didn't help much after running for 14 hours where 10 of them was with SWAN_SYNC=0 it was only at 24%. It was an improvement, since before SWAN_SYNC=0 4% was achieved after 4 hours so roughly it got a 100% boost, but 50 hours for a 6.08 WU on a GTX260(216) was unacceptable so I canceled after 14 hours. http://www.gpugrid.net/result.php?resultid=2409494

---

so, the problem is 6.08, but not the variable

---

Installed my brand new GTX 470 yesterday om my LINUX machine.
Uploaded a new WU and started crunching a 6.06 after a couple of minutes.
However, the speed was excruciating slow - a percentage tick every 28-30 seconds, So I decided to try something - I changed the nice value from 10 to 4 and as by miracle the turtle turned into a hair. Now a percentage tick in less than 2 seconds average.
Unfortunately I then had to leave for some duty travel. Coming back today I found out that
- the first WU was turned in successfully well under 3 hours time
- the following second WU though had only reached 24% after some 22 hrs runtime, so I changed the nice value again to 4. An hour or so later it reached already 66%

Anybody that knows how to permanently (i,e, so it sticks after every restart) change the nice value of a programme?

Kind regards

Alain

You can probably write a script / program to poll the active tasks and to react accordingly. Could be easier to leave one CPU core free, though. That is assuming your CPU is currently running comething else on all other cores?

And you may want to take a look at creating the environment variable "SWAN_SYNC" and setting it to "0". It's been posted somewhere (also how to do it under linux) and is usually required to get maximum performance out of Fermis.

MrS

---

Scanning for our furry friends since Jan 2002

Thanks for your advice Mr S.
I freed up one CPU core and set the SWAN_SYNC to 0.
Now the speed is acceptable.
However, changing the nice value to 4 still gives a very good speed rise.

But that will be for later...

Good night

Alain

Thanks for your advice Mr S.
I freed up one CPU core and set the SWAN_SYNC to 0.
Now the speed is acceptable.
However, changing the nice value to 4 still gives a very good speed rise.

I see a speed increase by setting the priority to normal in windows. CPU time rises very little and responsiveness of the system is unaffected. Wish there was a switch to allow this as the syan_sync setting seems like complete overkill, wasting a CPU core when what is really needed is a priority bump or better yet settings like Collatz and MilkyWay use:

One can configure the app through some parameters in the supplied app_info.xml.
This is done by editing the line

<cmdline></cmdline>

There are several options one can put in there, the order does not matter. If the same argument
is given twice, the last one counts. Remember that for editing the app_info.xml one should take
the same precautions as for the installation of the application, i.e. one should stop BOINC
completely and restart it afterwards.

Options:

kernel frequency: f (default 30)
The application determines the size of the work packages sent to the GPU in a dynamic manner. It
tries to get the number of executed packages per second above the value specified here by
splitting them to smaller ones. The OS is completely blocked from accessing the graphics card for
the duration of one package leading to a somewhat sluggish behaviour of the user interface.
Limiting the size and therefore reducing the execution time per package creates more opportunities
for the OS to slip in between two work packages and to react to user input. The default value of
30 Hz is tuned for usability of the system. Reducing it could increase the throughput of the app
slightly.

Example:
<cmdline>f10</cmdline>
The app will try to run 10 work packages per second (limits the execution time to 100ms or shorter).


Wait factor: w (default 1.0)
The app tries to release the CPU during the the GPU computations. It does so by predicting
the runtime for the GPU calls and send the CPU thread to sleep for that time. One can manually
correct the prediction of the application with this factor. When raising it, the CPU thread
sleeps longer, decreasing the value will lead to a faster wakeup of the thread. After that time,
the polling of the GPU starts. Setting this value to 0.0 turns off the release of the CPU.
Default is of course a value of 1.0. If you see a low GPU load, you can try to decrease it (if
you have a load of 80%, set it to 0.8). If you see a high CPU load, a slight increase of this
value may help. Increase it too much and it will affect the crunching speed. You could use this
for throttling of the GPU in case the high GPU load leads to a very sluggish behaviour of the
user interface or even VPU recover events. Setting w1.1 could improve the situation (see also
the f, b and p options).

Example:
<cmdline>w1.3</cmdline>
This would increase the sleep time by 30% in relation to the prediction.


Maximum GPU RAM use: r (default 33.4)
The application allocates memory on the graphics card to store the calculated steps. Increasing
the size can offer more parallel data to process and the f option more room to get the real
setting closer to its specified value. But you should not increase the RAM usage, if more than
one WU are processed concurrently. The value is given in percent relative to the installed amount.
Too high or too low values can crash the application, so be careful! See also the explanation
about the graphics RAM usage at the end of the readme.

Example:
<cmdline>r25</cmdline>
This would decrease the maximum RAM usage to 25%.


Priority: p (default 2)
All BOINC applications normally run with the lowest possible priority to not disturb other
applications. This can lead to a low GPU load, as it may be not possible to fire up the next tasks
if all cores of the CPU are under load. Raising the priority may help here. BOINC recommends a
slightly increased priority for GPU applications. This setting is the default. Possible values:
p0: idle priority, used by CPU BOINC applications
p1: normal priority in idle priority class (below normal), this is recommended for BOINC GPU
applications, but apears to be not enough to enable millisecond polling of the GPU with Vista
p2: normal priority in normal priority class, the default
p3: normal priority in high priority class, use with care!
The priority will affect how much time it takes for the the app to get back control if it releases
its time slice (see also option b).

Example:
<cmdline>p3</cmdline>
This raises the priority to high (not recommended).


Polling behavior for the GPU within the Brook runtime: b (default 1)
See the option w for starters. If that time has elapsed, the GPU polling starts. This can be done
by continously checking if the task has finished (b-1), enabling the fastest runtimes, but potentially
creating a high CPU load (a bit dependent on driver version). Second possibility is to release the time
slice allotted by the OS, so other apps can run (b0). The catch is that there is some interaction with
the priority. The time slice is only released to other tasks of the same priority. So raising the priority
effectively disables the release and the behavior is virtually identical to setting this parameter
to -1. If a raised priority and a low CPU time is wanted, one should leave it at the default of 1. This
suspends the task for at least 1 millisecond, enabling also tasks of lower priority to use the CPU in the
meantime. One can use also b2 or b3 if one wants a smoother system behaviour.
Possible values:
b-1: busy waiting
b0: release time slice to other tasks of same priority
b1, b2 or b3: release time slice for at least 1, 2, or 3 milliseconds respectively
See also options p and w.

Example:
<cmdline>b-1</cmdline>
Enable busy waiting (no release of the time slice during polling).

For my systems all I have to do is add b-1 to the commandline to get GPU usage to 99%. Similar options to those above would be welcomed in GPUGRID.

"The nice value", is exactly what?

Boinc could really do with a GPU Tab!

PS. Messing with process priorities and affinities can cause crashes!

The amount of "Nice"ness is how happily a *nix program hands cpu control over to another one (actually the scheduler decides based on nice values). It's a different kind of process priority. Who ever manages to change it is probably aware that changing this could cause problems ;)

MrS

---

Scanning for our furry friends since Jan 2002