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!

Since February 5, I had swan_sync=0 in my .bashrc file. Then after reading a bit of Lem's post, I tried moving it to /etc/profile. That didn't work, so I put it in /etc/environment. It still doesn't show up in the workunit logs. And yes, I did reboot. Can't play any of my favorite games unless I switch over to Windows.

That said, manually manipulating the Linux CPU scheduler did the trick. It allowed the fourth core in my i5-750 to run both a CPU task and GPUGrid at the same time. GPUGrid still took the same amount of time to finish as before. True, the CPU task runs a tiny bit slower because it has to share CPU time with GPUGrid, but at least every core is running at 100%.

As for the shortage of workunits, I have DNETC as a backup for my GPU. Unlike GPUGrid (at least in the present), DNETC runs my GPU at 100% load.

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:

     export SWAN_SYNC=0

and it worked. It gave my GT240 about a 20% improvement.

I don't know about other distros but that's what it took on my Fedora 14 x86_64 system to get swan_sync enabled.

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.

Greg,

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.

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.

Greg

Glad it worked for you.

Ah, no, I do not actually use swan_sync. But I'm happy you found a way to have it working on your system, despite my advice about /etc/environment didn't help you.

Here I have no need to save a whole cpu core for gpugrid: I have exacly the same performance without wasting cpu power. Having just 2 cores, both are precious for me. :)

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.

Yep. 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.

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.

I don't know what to tell you. I set up SWAN_SYNC in /etc/environment. I was able to open a command window and echo the SWAN_SYNC value no problem. So the default readenv=1 behaviour is there. However, it had no impact on the behaviour of the acedm2 app.

Only when I add the "export SWAN_SYNC=0" command to the boinc-client init script did acedm2 enable SWAN_SYNC.

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.

As Einstein had some difficulties with WU creation this week I crunched some new WUs, this time with the new app 6.14. Unfortunately I forgot to delete the swan_sync rubbish before, and so I wasted precious resources with this idiotic stuff again.

93-KASHIF_HIVPR_GS_so_ba1-8-100-RND2726_1 96,510.67 	1,336.56 	12,822.18 	16,027.72

98-KASHIF_HIVPR_cut_ba1-45-100-RND5086_1 	95,885.94 	74,305.64 	5,929.17 	7,411.47 

The upper one was without swan_sync, the lower one with it. Niceness was 19 with the lower one, and -5 with the upper one. You can clearly see, both took about the same amount of wall clock time, but without swan_sync the CPU-time was extremely less. You can as well see that the upper one had done more than double the scientific work as the lower one, as credits, given as a fix by the project, are more than double for the upper one.

To sum it up:
Swan_sync on a GT240 is a giant waste of resources.
Fanboys who proclaim otherwise are either dumb or liars.
Niceness is crucial, swan_sync is detrimental.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

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.

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.

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.

The app is called ACEMD2: GPU molecular dynamics v6.14 (cuda31) for Linux, as can easily be seen on the apps page, the old app was called ACEMD2: GPU molecular dynamics v6.13 (cuda31).

As I said before in other posts, it uses a whole CPU if swan_sync is put to 0 and nice stays at -10 as delivered by project.
The use of more CPU-power is detrimental to the clock time of the WU, I have shown several times.

If a WU gets the same amount of credit granted as another, it's about the same as the other in size. Credits are determined by the project unrelated to anything on my machine.
If a WU gets more credits than the other, it has done more scientific work.
I've crunched 2 WUs of the same type (KASHIF_HIVPR), both took the same amount of time, but one used for the whole time the CPU as well, the other nearly not.
The one without using the CPU did far more than double the scientific work done in this time, as is shown in more than double credits, than the one without much CPU-use.

Obviously Starving the GPUGrid task of any CPU time makes it really really much more efficient.

Edith says:
As my thanks were gone as well, here they are again (to Message 21755):

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.

Thanks for this very useful information. I would have appreciated this to have come from the project people, I don't know why they said otherwise.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

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.

Thanks for this very useful information. I would have appreciated this to have come from the project people, I don't know why they said otherwise.

I will quote myself from the distant past (321days ago),
"If a CPU core is allocated to the Fermi GPU it significantly increases the GPU speed, especially if you use SWAN_SYNC=0. This is the recommended configuration for Fermi users, especially GF100 cards".

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 will quote myself from the distant past (321days ago),

OK, that was the thread where gdf tried to push the swan_sync-stuff to me with force, starting here.
The thread after the fiasco with the new rubbish 6.12 app.

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).

I never looked in that thread, title was nothing that looked like it would be helpful for my problems, it's about hardware, while my prob is software.

"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)

The title "Lots of failures" doesn't sound like something for my prob, why should I look it up there?
And if it was "Windows only" in this thread, why did you try so hard to make me use it under Linux in the other one?

"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)

Thread title "Fermi", why should I look in there?

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.

That's absolutely irrelevant insider talk for me, it's apps delivered by the project, that worked fine with the name 6.05 attached, that went unusable with 6.12 attached, and then all you project people tried to
a) make me use the newest drivers, otherwise I would have problems
b) make me use swan_sync=0, otherwise I would have problems²
c) make me use older drivers, otherwise I would have problems

² the ways to make swan_sync=0 work were told me in different ways by the project people, none was helpful, I managed to make it work with the help of Leo, and it showed the use was completely rubbish.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

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.

How exactly can I configure the thread priority in the Windows app?
I can't recall and I can't find any messages about doing this.
Perhaps you mean thread priority being configurable by the programmers?

"thread priority being configurable in the Windows app"
Yes, I meant configurable by the programmers for the ACEMD apps, not by us.
You could view the priorities from Process Explorer, but you cannot configure them.

ATM the different apps and tasks perform to a variety of standards (GPU Utilizations). The short tasks for the Windows 6.15app seem to run at higher GPU Utilization, and without using SWAN_SYNC; While running an IBUCH_GCY task, I'm seeing a steady 95 to 96% GPU Utilization, without SWAN_SYNC on, and without freeing up a CPU thread (i7-2600). Was getting around 85% for the longer tasks (with more credit/h). For a GTX260 using SWAN_SYNC on W7 and freeing up a CPU core only increased the GPU utilization by 4% for the long tasks. Don't know what the performance is like for the 6.14app for different GPU types. I expect it is still significantly higher for Fermi's when using SWAN_SYNC and freeing up a CPU core, only slightly for the CC1.3 cards, and would make no difference to the other cards (unless you are not using the CPU at all and the CPU downclocks, in which case SWAN_SYNC forces the CPU core to stay at a high frequency).