SETI MB CUDA for Linux

[pp]

The default priority of nice 10 seems to slow the process down on my box, once I switched it to 0 or -5, it processed much faster and collected up CPU time quicker.

Is there a way to control the SETI apps' default nice level through the configuration files? The nice level is supposed to be inherited from the parent app but default on my computer, BOINC has 0, AK_V8_linux64_sse3 has 19 and setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu has 10 so obviously there's something I don't understand here. Right now I'm using an external daemon to renice the processes now and then.

[sunu]

BOINC has 0, AK_V8_linux64_sse3 has 19 and setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu has 10 so obviously there's something I don't understand here. Right now I'm using an external daemon to renice the processes now and then.

Renice them to what? Those priority levels are good for a system that you work on. Unless it is a dedicated cruncher.

And how your cuda client starts at 10? Mine always starts at 19 and have to lower it with a script.

[pp]

Well, running two CPU instances at nice 19 and one CUDA at nice 10 on this dualcore makes the CUDA task take several hours. Renicing the CUDA task to -5, like koschi mentioned, one CUDA task completes in 23 minutes on this 9800GT. It's almost a dedicated cruncher. It's my gaming rig but I don't use it often.

[koschi]

For the box where I tried this, it really made a difference. Those days I was running Docking@home on the CPU, might not be that dramatic with other CPU projects.
I use a one line command in cron, being executed once per minute, renicing all cuda processes to -5. The system is just crunching and serving files, so no issues if the interface would get a little choppy or not

[sunu]

Back in the days when cuda needed a whole core, I was running a 3+1 config in my quad core. All processes had the lowest priority (19) and I don't think I had any serious slowdown, maybe a minute or so, not more. And this was my everyday desktop so many things were running, firefox with many many tabs, full 3d compiz effects, everyday backups, etc.

Only now that cuda shares a core with the other seti@home tasks, I started renicing them only to make them higher priority than the other seti@home instances. I think -5 is not necessary.

[riofl]

Back in the days when cuda needed a whole core, I was running a 3+1 config in my quad core. All processes had the lowest priority (19) and I don't think I had any serious slowdown, maybe a minute or so, not more. And this was my everyday desktop so many things were running, firefox with many many tabs, full 3d compiz effects, everyday backups, etc.

Only now that cuda shares a core with the other seti@home tasks, I started renicing them only to make them higher priority than the other seti@home instances. I think -5 is not necessary.

i tried setting the AK MB cpu apps to 10 and the cuda ones to  -5 and after 24 hrs there was very little difference in my scores. the only thing that happened is my desktops became difficult to work with and gave me the impression i was working with my old p3 933mhz machine so i returned them to boinc defaults of 19 and 10.

[sunu]

A small update for those with multi-gpu systems.

The problem with proper multi-gpu support in linux with recent boinc releases seems to have been fixed (got a message yesterday from David Anderson and I confirmed it compiling boinc and running it).

But now there seems to be another problem with task scheduling. Richard Haselgrove hinted that maybe this problem is general since there have been similar reports that this might also occur in windows. If it is so we might get a faster fix this time.

Well, anyway, we are one problem down. I hope we get a proper functioning boinc in linux soon.

[Kunin]

Great news!  Maybe soon I won't have to use 6.4.5 for crunching and 6.6.11 for downloading (for some reason 6.6.11 would randomly stop using the GPUs, but 6.4.5 always says high priority so would never download new WU).

[sunu]

Great news!  Maybe soon I won't have to use 6.4.5 for crunching and 6.6.11 for downloading (for some reason 6.6.11 would randomly stop using the GPUs, but 6.4.5 always says high priority so would never download new WU).

6.6.11 has a bug that if a GPU job is running,and a 2nd GPU job with an earlier deadline arrives, neither job is executed ever. Maybe you get hit by this.

I use a script running in an infinite loop to notify me when this happens. Then a boinc restart fixes it... until next time. Also turning off "leave applications in memory while suspended" in your computing preferences seem to help a bit, but it doesn't solve it completely.

[Kunin]

Sounds like it since it happens randomly.  On days I work (12 hour shifts) I'm at my computer maybe 3-4 hours, so odds of me catching it is slim, hence I use 6.4.5 for crunching.  I just switch to 6.6.11 to download 5-10 days cache, rebrand it all and then back to crunching.

[riofl]

Great news!  Maybe soon I won't have to use 6.4.5 for crunching and 6.6.11 for downloading (for some reason 6.6.11 would randomly stop using the GPUs, but 6.4.5 always says high priority so would never download new WU).

6.6.11 has a bug that if a GPU job is running,and a 2nd GPU job with an earlier deadline arrives, neither job is executed ever. Maybe you get hit by this.

I use a script running in an infinite loop to notify me when this happens. Then a boinc restart fixes it... until next time. Also turning off "leave applications in memory while suspended" in your computing preferences seem to help a bit, but it doesn't solve it completely.

wow. never knew that... i dont see that in my system but that is because i run the cpugpu perl script often to catch random downloads so boinc gets restarted several times an hour.

soon as the scheduler gets fixed ill give the new one a shot

[sunu]

Sounds like it since it happens randomly.  On days I work (12 hour shifts) I'm at my computer maybe 3-4 hours, so odds of me catching it is slim, hence I use 6.4.5 for crunching.  I just switch to 6.6.11 to download 5-10 days cache, rebrand it all and then back to crunching.

Well, you could use a script to restart boinc automatically when the bug kicks in. I didn't do it because I didn't like too much complexity and at the end I preferred I have the control over boinc restart.

wow. never knew that... i dont see that in my system but that is because i run the cpugpu perl script often to catch random downloads so boinc gets restarted several times an hour.

Restarting boinc several times an hour surely squashed that bug. 

soon as the scheduler gets fixed ill give the new one a shot

Yesterday, some changes to the scheduler were introduced. The problems I posted above, it seems, were across all platforms as the changes were generic. The battle with task scheduling in boinc is an ongoing and never ending one.

I haven't checked boinc with the new changes to see how it runs. Feel free to check it. At last we'll have a "modern" boinc release with proper multi-gpu support in linux in the next round of "official" releases.

[riofl]

Restarting boinc several times an hour surely squashed that bug. 

Yesterday, some changes to the scheduler were introduced. The problems I posted above, it seems, were across all platforms as the changes were generic. The battle with task scheduling in boinc is an ongoing and never ending one.

I haven't checked boinc with the new changes to see how it runs. Feel free to check it. At last we'll have a "modern" boinc release with proper multi-gpu support in linux in the next round of "official" releases.

what version is it? the latest i see in http://boincdl.ssl.berkeley.edu/dl/ is 6.6.37 or do i have to use svn and hope for the best?

[sunu]

or do i have to use svn and hope for the best?

Yes, you have to compile from source.

[riofl]

or do i have to use svn and hope for the best?

Yes, you have to compile from source.

ok hope i got the right one. never did 'get' what to do with svn there are so many different sources. looks like the one i got was trunk 6.9.0. is that the correct one?