Hi guys!
I've just set up a system with an NVIDIA GT240 GPU card and a dual core CPU. It's running Linux Ubuntu 10.04 64bit.

Nvidia driver is 195.36.24: a 6.12 app has been downloaded, which I think is fine for this cuda card, and crunching is going up of 0.1% every minute, so the whole workunit should take about 60,000 seconds. It seems in average.

I'd like to let you know a thing I've noticed, and to ask you a couple of questions.

First, my "report". LOL.
The gpugrid wu now being crunched wants 0.16 CPUs (however it doesn't go beyond 2%-3% load) and the GPU. The app runs with a niceness of 10 by default - whilst other CPU boinc apps (boincsimap, WCG...) run with a niceness of 19. I've found that 10 vs 19 is not enough: when the CPU is saturated, even by "idle" applications running at 19, the gpu almost stops working, its temperature falls and the gpugrid app becomes ways slower: many many times slower. Renicing gpugrid app to -1 has given it back its normal speed.
I have not tested any other values for now.

So my first question is: is there a simple way to tell boinc to set to -1 the niceness for gpugrid apps?

My second question is about overclocking the GPU. I know about the

Option "Coolbits" "1"

line in the Device section of /etc/X11/xorg.conf.
But it gives the chance to overclock only the GPU and the memory, while I happen to know that is the shader frequency that matters most. How could I rise it?

Thanks in advance for everything,
and bye.

If you free up a CPU core, use swan_sync=0, and report tasks immediately it should help a lot:

I don't know of a way to only overclock the shaders from within Linux.

From what I read the problem is that nice/renice settings tend to be lost on restart

Nope, that didn't work for me. I tried changing the niceness to -1 and then let rosetta@home run on all four cores on my i5 750, but rosetta@home effectively shut out the GPUGrid application (no meaningful work was being done by the GPU). This occurred even when the rosetta@home apps were running with a niceness of 19 and GPUGrid running with a niceness of -1.

Nope, that didn't work for me. I tried changing the niceness to -1 and then let rosetta@home run on all four cores on my i5 750, but rosetta@home effectively shut out the GPUGrid application (no meaningful work was being done by the GPU). This occurred even when the rosetta@home apps were running with a niceness of 19 and GPUGrid running with a niceness of -1.

To elucidate further, I am currently using Linux Mint 10 with kernel version 2.6.35-25-generic. My GTX 570 is using the latest stable Linux driver version, 260.19.36. And yes, I am using version 6.13 of the GPUGrid CUDA app. It certainly would be nice if the Rosetta app running on that fourth core would slow down a little bit just so that the GPUGrid app can get some CPU time in.

Hi, I seem to change the priority of the GPU through the GUI "System Monitor" in Ubuntu 10.10, each time you load a new task, ie between 5 to 8 hours (for my GTX295) is no problem or nuisance.

Personally I would comment that I use the system to move the two tasks of the GPU of the priority level "10 " starts GPUGRID default to "0" when I'm working normal with the PC and move it to "-10" in hours that do not use it anyway with the highest priority is not low on overall response on the computer (i7-930, 6GB RAM). Greetings.
____________
http://stats.free-dc.org/cpidtagb.php?cpid=b4bdc04dfe39b1028b9c5d6fef3082b8&theme=9&cols=1

I don't know of a way to only overclock the shaders from within Linux.

Hi, I seem to change the priority of the GPU through the GUI "System Monitor" in Ubuntu 10.10, each time you load a new task, ie between 5 to 8 hours (for my GTX295) is no problem or nuisance.

Personally I would comment that I use the system to move the two tasks of the GPU of the priority level "10 " starts GPUGRID default to "0" when I'm working normal with the PC and move it to "-10" in hours that do not use it anyway with the highest priority is not low on overall response on the computer (i7-930, 6GB RAM). Greetings.

I would very much appreciate a setting in my account or my BOINC (or my ubuntu, if there is a more permanent way of doing so outside System Monitor), that would keep the app at the desired nice level.

I would very much appreciate a setting in my account or my BOINC (or my ubuntu, if there is a more permanent way of doing so outside System Monitor), that would keep the app at the desired nice level.

I have put in my /etc/crontab the line:

*/5 * * * * root renice -1 $(pidof acemd2_6.12_x86_64-pc-linux-gnu__cuda) > /dev/null 2>&1

Saenger,

All the stuff with swan_sync, freeing of a core or such doesn't change anything on this machine, it's just a smokescreen to pretend giving clues.

Yet another misleading and disrespectful message!

Your 98.671 ms per step performance for a GIANNI_DHFR1000 is exceptionally poor for a GT240

Using the recommended config (even on vista; over 11% slower than Linux), using swan_sync and the 6.12 app, 22.424 ms per step

...and yet there is no mention of swan_sync in your task result details.

I'm beginning to suspect that the reason swan_sync isn't working is because the environment variable is associated with the wrong user. GPUGrid tasks don't run at the user level. Rather, the user is boinc.

I installed BOINC using the package manager. Rather than adding

As you know you can add export SWAN_SYNC=0 to your .bashrc file

I still fail to grasp why this extremely nerdy stuff isn't simply put in the app, especially as GPUGrid worked nearly fine and smooth until the last change of app, it just had to acknowledge it's use of a whole core, like Einstein does now, and everything would have been fine.

Now it's a project for nerds or windoze.
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

While there are a few how to use Linux threads, there is not a sufficient how to optimize for Linux thread. If I get the time I will try to put one together, but such things are difficult when you are not a Linux guru.

I tried changing the niceness of the GPUGrid task to -10 (defaulted to 19). Then I set BOINC to use 100% of the processors. I wanted to see if the priority change would allow Rosetta@Home and GPUGrid to share CPU time in the fourth core. It still seems like Rosetta@Home is being greedy with the CPU, causing GPUGrid to slow down drastically. The Rosetta@Home task in the fourth core was using 99-100% of that particular core. The kicker was that the niceness for Rosetta@Home tasks is set at 19! It really appears that swan_sync doesn't do anything at all. It certainly isn't showing up in the stderr section when I look at my completed tasks.

Just to reiterate, I'm using Linux Mint 10, which is based on Ubuntu 10.10.

I tried changing the niceness of the GPUGrid task to -10 (defaulted to 19). Then I set BOINC to use 100% of the processors. I wanted to see if the priority change would allow Rosetta@Home and GPUGrid to share CPU time in the fourth core. It still seems like Rosetta@Home is being greedy with the CPU, causing GPUGrid to slow down drastically. The Rosetta@Home task in the fourth core was using 99-100% of that particular core. The kicker was that the niceness for Rosetta@Home tasks is set at 19! It really appears that swan_sync doesn't do anything at all. It certainly isn't showing up in the stderr section when I look at my completed tasks.

acemd2_6.13_x86
pid 2993's current scheduling policy: SCHED_IDLE
pid 2993's current scheduling priority: 0
pid 2993's current affinity mask: f

minirosetta_2.1
pid 2181's current scheduling policy: SCHED_IDLE
pid 2181's current scheduling priority: 0
pid 2181's current affinity mask: f

As you can see, they're exactly the same. At this point, all four cores are being used, and GPUGrid has a niceness of -10.

It works! Now I can run four CPU tasks and a GPUGrid task at the same time! Thank you very much! This is much better than the swan_sync method that is often spoken of here.

Another thing: does this need to be in rc.local as well? Or would crontab suffice? Additionally, does the chrt command need the terminal output suppression thingy at the end in crontab? (... > /dev/null 2>&1)

It works!

Another thing: does this need to be in rc.local as well? Or would crontab suffice? Additionally, does the chrt command need the terminal output suppression thingy at the end in crontab? (... > /dev/null 2>&1)

I've got something to compare:
After the post by Lem Novantotto I tried another version of using SWAN_SYNC, nothing with those non-existing .bashrc stuff, that project fanboys tried to impose, but this etc/environment stuff. It had some grave consequences:

I've got two similar WU, or at least they should have been according to the credit settings by the project, one before the change and one crunched yesterday.

Old one, 76-KASHIF_HIVPR_n1_bound_so_ba2-92-100-RND2370_0:
- crunched with nice factor -1
- crunched with SWAN_SYNC_0 according to fanboy instructions, but obviously not in reality according to stderr.out
- Time per step (avg over 575000 steps): 61.307 ms
- Run time 77,243.59 seconds
- CPU time 1,577.01 seconds

New one, 16-KASHIF_HIVPR_n1_bound_so_ba2-94-100-RND9931_0:
- crunched with nice factor 10
- crunched with SWAN_SYNC=0 according to Lem, this time mentioned in stderr.out
- Time per step (avg over 325000 steps): 82.817 ms
- Run time 102,772.46
- CPU time 102,095.10

As you can see the main difference is the usage of massive CPU-power with the result of significantly reducing the crunching speed.
It behaved like before the app change, i.e. it pretended to be 0.15 CPU + 1 GPU, while it used 1 CPU + 1 GPU, leaving 3 cores for the concurrent 4 WUS of other projects.
I started with both, nice forced to -1 and new swan_sync, but it left one core idling, somehow it gave the other 4 projects in parallel not more than 2 cores according to System Monitor, so I commented that line in crontab out.

This new method is definitely not useful, I will never try it again. It's a massive waste of resources.

Next try, after Einstein got it's usual share again, will be with a forced nice factor of 19, so the 4 cores will be divided evenly to the 5 WUs, as it worked fine with the old app.
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

This time I got a Gianni, but I still have one of those with 7,491.18 credits in my list from before as well. Here's the data:

old: 251-GIANNI_DHFR1000-34-99-RND0842_1
- crunched with nice factor -1 or -3 I don't remember exactly
- crunched with SWAN_SYNC_0 according to fanboy instructions, but obviously not in reality according to stderr.out
- Time per step (avg over 25000 steps): 98.671 ms
- Run time 81,994.45 seconds
- CPU time 2,106.21 seconds

new: 800-GIANNI_DHFR1000-37-99-RND6435_1
- crunched with nice factor 19
- crunched with SWAN_SYNC=0 according to Lem, this time mentioned in stderr.out
- Time per step (avg over 1905000 steps): 41.600 ms
- Run time 83,551.62
- CPU time 66,219.42

So again no speed up, just a waste of CPU-power, but at least not slower than the old one ;)

I think I bugger this swan_sync rubbish and stick to the priority alone. It's simple and it works. and it's far more effective than wasting precious CPU-time for slow-down.

Edith says:
I don't have a clue what these ms/TS are, they are obviously something completely different for both WUs, TS don't seem to relate to work done. Credits are defined by project, so both WUs did the same amount of work according to project, the new one just needed more time steps for the same work done.
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

There is no getting away from the fact that the 6.13app is slower for GT240 cards, which is why I use the 6.12app, albeit driver dependent.

You have to leave a CPU core free when using swan_sync, otherwise its not going to be faster for the GPU.

There is no getting away from the fact that the 6.13app is slower for GT240 cards, which is why I use the 6.12app, albeit driver dependent. Your drivers are for Einstein, not GPUGrid.

I have to agree with Saenger on this one, which is a pretty rare thing. I have noticed no difference with swan_sync + free core. This is on a win7 machine with a 580, which is a different setup than this thread subject. But my impression is similar about these tweeks that are supposed to speed things up.
____________
Reno, NV
Team: SETI.USA

Yep, I agree. There is no difference whatsoever with swan_sync on or off for my GTX 570. It will still run for about 4.5-5 hours.

On another note, it seems as if the server is running low on workunits to send out. I see only one workunit ready to send out. Could this be in preparation for the upcoming long workunits?

Lem Novantotto,
Do you think the 270.18 driver caused the card to run in low power/clock mode (a common issue on Win with recent drivers)?

Cuda 3.0 (3000)= 6.12app
Cuda 3.1 (3010) or [above] (for now)= 6.13app
[above] can be 3.2 or 4.0

I would not expect too much in the 270.18 driver for a GT240, just for the latest and next versions of Fermi.

My card is running stock speed.

Other cuda projects run at consistent speeds, no variation.

Edit: and yes, I rebooted.
____________
Reno, NV
Team: SETI.USA

You don't have swan_sync enabled and none of your tasks to as far back as 5th Feb have actually used swan_sync!

I previously tried to enable swan_sync with similar success to others in this thread. Even renice -1 had no effect. I decided to try it again and after adding it to /etc/rc.d/rc.local, /etc/bashrc, /etc/profile and /etc/environment I still could not get it to work.

I finally added the following to the start() section of the /etc/rc.d/init.d/boinc-client:

I previously tried to enable swan_sync with similar success to others in this thread. Even renice -1 had no effect. I decided to try it again and after adding it to /etc/rc.d/rc.local, /etc/bashrc, /etc/profile and /etc/environment I still could not get it to work.

Your solution works flawlessly. Well done!

Since I don't know Fedora, could you please help me understand? I suspect that Fedora's PAM configuration is slightly different with respect to Ubuntu's one. I guess that running:

$ grep "pam_env.so" /etc/pam.d

you'll get some output containing "readenv=0". Is it true?

Thanks.
Bye.

Glad it worked for you.

I ran the grep command and there were no entries on my Fedora system with readenv. I assume that implies readenv=0.

Out of curiosity, since I haven't done a lot of monkeying around with PAM I ran the same command in my Ubuntu install (running in VMWare) and it shows a number of entries with readenv=1.

However I'm pretty sure readenv=1 is the PAM default (readenv=1 tells pam_env.so to read /etc/environment).

Lacking any readenv=0, I do not understand why your /etc/environment isn't read. I may be wrong about the default PAM behaviour, of course.
I'll try a little bit harder.

Bye, and thank you again. :)

However I'm pretty sure readenv=1 is the PAM default (readenv=1 tells pam_env.so to read /etc/environment).

Lacking any readenv=0, I do not understand why your /etc/environment isn't read. I may be wrong about the default PAM behaviour, of course.
I'll try a little bit harder.

Bye, and thank you again. :)

I've just tried on a live virtualized fedora 14, and /etc/environment is actually read.
I don't know why on your system it is not. Sorry, I have to give it up.

Bye.

My 4x580 Ubuntu rig has been working fine for some time using swan_sync=0 in /etc/environment. Yesterday I had to relocate it, but after booting up I noticed it was no longer using full cores. I typed env in the terminal and it showed swan_sync=0 was listed. However, upon checking /etc/environment, swan_sync was missing. Added it back and now ok again.

After the discussion here I've noticed that there are some differences with the way the two most common distros, Ubuntu and Fedora/Red Hat, process the environment.

I've just changed my system to put the "export SWAN_SYNC=0" command in the /etc/sysconfig/boinc-client file. I believe the equivalent file on Ubuntu is /etc/default/boinc-client.

This has the advantage of limiting the scope of the SWAN_SYNC value to the BOINC client environment and shouldn't be affected by any operating system or BOINC client updates.

Any thoughts?

Hello: Well, I have configured my Ubuntu 10.10_64bits with SWAN_SYNC in "etc / environment" working perfectly.

Also comment that I find it interesting to modify the configuration of BOINC Manager Preferences + Advanced + Processor Usage = "Switching between applications each = 15 minutes instead of the normal 60 minutes.

With SWAN_SYNC=0 places the CPU connected to the GPU, in my case two to have a GTX295, 100% and so every 15 minutes change the processor in use by the GPU to avoid overheating and better distributing the load on CPU multicores. Greetings.
____________
http://stats.free-dc.org/cpidtagb.php?cpid=b4bdc04dfe39b1028b9c5d6fef3082b8&theme=9&cols=1

I think I bugger this swan_sync rubbish and stick to the priority alone. It's simple and it works. and it's far more effective than wasting precious CPU-time for slow-down.

To sum it up:
Swan_sync on a GT240 is a giant waste of resources.

Sanger, you are comparing two different task types, using different niceness settings and concluding that swan_sync makes the tasks slower, despite knowing that SWAN_SYNC would need to be used alongside a free core even if it did make much difference for that GPU type. Starving the GPUGrid task of any CPU time would obviously make it less efficient.
By the way, the new app is 6.15 not 6.14, and it's for Windows not Linux.

To sum it up:
Swan_sync on a GT240 is a giant waste of resources.

No wonder, SWAN_SYNC was introduced to handle the low GPU usage of Fermi based cards.

I will quote myself from the distant past (321days ago),

I expect SWAN_SYNC would make little or no difference for a 9800GT, or any other CC1.1 card; it is mainly for Fermi's (317days ago).

"The Windows only optional variable SWAN_SYNC=0 is for Fermi's and does not have to be used along with one free core but it usually helps a lot. It will make little or no difference to the performance of a 9800GT. There is little need to leave a CPU core free, unless you have 3 or 4 such cards in the same system, at which point your CPU performance for CPU only tasks will degenerate to the point that you might as well free up a CPU core. On a high end Fermi it is still optional but generally recommended to use both SWAN_SYNC=0 and to leave a Core/Thread free; the performance difference is quite noticeable." (266days ago)

"For a GTX260 this is not the situation; you don’t need to free up a CPU core or use SWAN_SYNC=0" (251 days ago)

It's worth remembering that there have been 5 different apps since SWAN_SYNC was originally only used for Linux (within the app by default). At different times SWAN_SYNC either made or didn't make a difference for Linux or Windows, if setup correctly, for different cards in the past. Whatever the situation you or anyone else previously found themselves in is no longer relevant; we are onto 6.14 and 6.15. I have not tried any GPU under Linux for the present 6.14app, and found that my GT240's kept downclocking with the latest Win drivers, so I pulled those cards.

I think both Windows and Linux apps were named 6.14 and released on the 12th Jun 2011, with only the Windows version being subsequently updated to 6.15 (on the 6th Jul); thread priority being configurable in the Windows app but not the Linux app.

I think both Windows and Linux apps were named 6.14 and released on the 12th Jun 2011, with only the Windows version being subsequently updated to 6.15 (on the 6th Jul); thread priority being configurable in the Windows app but not the Linux app.