2 video cards in linux. Boinc sees them as same device!

Have you noticed that sometimes 6.6.11 stops processing CUDA for no particular reason? It's done it a few times, I've just had to restart BOINC and it starts up again... very odd.

Did you know that 6.6.11 is, despite its numbering showing it to be a release version, in reality an ALPHA version? In other words that it is one of the development versions with test- and bug fixes going up to the nearest Public Release version 6.6.20?

6.6.12, the one following 6.6.11, has as possible fix for this problem you're talking about, namely amongst others:

- client: fix bug where if a GPU job is running, and a 2nd GPU job with an earlier deadline arrives, neither job is executed ever. Reorganized things so that scheduling of GPU jobs is done independently of CPU jobs.
The policy for GPU jobs:

* always EDF
* jobs are always removed from memory, regardless of checkpoint (GPU memory is not paged, so it's bad to leave an idle app in memory)

Did you know that 6.6.11 is, despite its numbering showing it to be a release version, in reality an ALPHA version? In other words that it is one of the development versions with test- and bug fixes going up to the nearest Public Release version 6.6.20?

6.6.12, the one following 6.6.11, has as possible fix for this problem you're talking about, namely amongst others:

- client: fix bug where if a GPU job is running, and a 2nd GPU job with an earlier deadline arrives, neither job is executed ever. Reorganized things so that scheduling of GPU jobs is done independently of CPU jobs.
The policy for GPU jobs:

* always EDF
* jobs are always removed from memory, regardless of checkpoint (GPU memory is not paged, so it's bad to leave an idle app in memory)

All changes from 6.6.11 onwards can be found in the Change Log thread.

Where you see when it says "This is a development version of BOINC." that it may indeed be a development version of BOINC and when it says "Public release", it isn't.

Did you know that 6.6.11 is, despite its numbering showing it to be a release version, in reality an ALPHA version? In other words that it is one of the development versions with test- and bug fixes going up to the nearest Public Release version 6.6.20?

6.6.12, the one following 6.6.11, has as possible fix for this problem you're talking about, namely amongst others:

- client: fix bug where if a GPU job is running, and a 2nd GPU job with an earlier deadline arrives, neither job is executed ever. Reorganized things so that scheduling of GPU jobs is done independently of CPU jobs.
The policy for GPU jobs:

* always EDF
* jobs are always removed from memory, regardless of checkpoint (GPU memory is not paged, so it's bad to leave an idle app in memory)

All changes from 6.6.11 onwards can be found in the Change Log thread.

Where you see when it says "This is a development version of BOINC." that it may indeed be a development version of BOINC and when it says "Public release", it isn't.

Did you know that 6.6.11 is, despite its numbering showing it to be a release version, in reality an ALPHA version? In other words that it is one of the development versions with test- and bug fixes going up to the nearest Public Release version 6.6.20?

6.6.12, the one following 6.6.11, has as possible fix for this problem you're talking about, namely amongst others:

- client: fix bug where if a GPU job is running, and a 2nd GPU job with an earlier deadline arrives, neither job is executed ever. Reorganized things so that scheduling of GPU jobs is done independently of CPU jobs.
The policy for GPU jobs:

* always EDF
* jobs are always removed from memory, regardless of checkpoint (GPU memory is not paged, so it's bad to leave an idle app in memory)

All changes from 6.6.11 onwards can be found in the Change Log thread.

Where you see when it says "This is a development version of BOINC." that it may indeed be a development version of BOINC and when it says "Public release", it isn't.

Right, we understand that, but 6.4.5 has issues and we're trying to find the best version that solves the issues we've mentioned in this thread.

I've gone through the code changes from 6.4.5 to 6.6.11 to 6.6.36 and I *think* I've found where the problem (original issue in this thread) is, but every attempt to compile the code (per: http://boinc.berkeley.edu/trac/wiki/CompileClient) has failed on the make in sea directory:

cp ../../../stage//usr/local/bin/boinc BOINC/boinc
cp: cannot stat `../../../stage//usr/local/bin/boinc': No such file or directory
make: *** [BOINC/boinc] Error 1

If I could get the compile to work I could run a few tests and hammer out the specific problem and report the fix back to the developers.

Tried that, errored right away looking for:

cp: cannot stat `../../../stage//usr/local/bin/boincmgr': No such file or directory

But boincmgr was never created, so can't copy it over...

Ha, got it working... now to run some tests and see if I can get it fixed!

So... got past that, but can't recompile the boinc client. Keep getting:

boinc_client-client_state.o: In function `CLIENT_STATE::init()':
client_state.cpp:(.text+0x5f08): undefined reference to `curl_version'
boinc_client-http_curl.o: In function `HTTP_OP::set_speed_limit(bool, double)':
http_curl.cpp:(.text+0x10d): undefined reference to `curl_easy_setopt'
http_curl.cpp:(.text+0x132): undefined reference to `curl_easy_setopt'

But I have curl installed...

So... got past that, but can't recompile the boinc client. Keep getting:

boinc_client-client_state.o: In function `CLIENT_STATE::init()':
client_state.cpp:(.text+0x5f08): undefined reference to `curl_version'
boinc_client-http_curl.o: In function `HTTP_OP::set_speed_limit(bool, double)':
http_curl.cpp:(.text+0x10d): undefined reference to `curl_easy_setopt'
http_curl.cpp:(.text+0x132): undefined reference to `curl_easy_setopt'

But I have curl installed...

Here's the modified script I use, it's pretty simple. Just run it (I've seen no harm in running while BOINC is, as it doesn't change anything) and it spits out something like:

VHAR on GPU: 12mr09ac.6289.7025.14.10.195
VHAR on GPU: 05dc08ae.32507.890.16.10.254
Number of CPU tasks:413
Number of GPU tasks:323
Number of VLAR tasks:330
Number of VHAR tasks:42
Total tasks: 736

You can't run it while downloading new WU, as it can't open the WU files to read them if they aren't there yet.

Right now (330 VLAR tasks) I've moved VHAR to GPU hence it complains about it, but you can see CPU has 413 tasks and there's only 330 VLAR so I should run the rebrand script again soon.

Here's the script:

$path="client_state.xml";

open (IN, $path);

$NumOfCPUTasks=0;
$NumOfGPUTasks=0;
$NumVLAR=0;
$NumVHAR=0;
$NumGPUToNumCPU_high_limit=25;
$NumGPUToNumCPU_low_limit=0.5;

while (<IN>) {
if( /<workunit>/ ){
#parsing result
$trueAR=-1;#error condition
$WUname="";
while(<IN>){
if( /<\/workunit>/ ){
open (WU, "projects\/setiathome.berkeley.edu\/" .$WUname) || die "ERROR: cant open task file " . $WUname;
while(<WU>){#reading task file and deciding where it should go
if( /<true_angle_range>(.*)<\/true_angle_range>/ ){
$trueAR=$1;
if( $trueAR == -1 ){
die "ERROR detected - cant determine AR value\n";
}
if($trueAR < 0.13){
$tasks{$WUname}=1;
$NumVLAR++;}
elsif($trueAR > 1.127){
$tasks{$WUname}=2;
$NumVHAR++;
}else{$tasks{$WUname}=3;}
last;
}

}
close(WU);
last;
}

if( /<name>(.*)<\/name>/ ){
$WUname=$1;
#print "task:\\".$1."\\ \n";
}
elsif( /<version_num>603<\/version_num>/ ){$NumOfCPUTasks++;}
elsif( /<version_num>608<\/version_num>/ ){$NumOfGPUTasks++;}


}

}

}
close(IN);
open (IN, $path);
while (<IN>) {
if( /<name>(.*)<\/name>/ ){
$WUname=$1;
#print "task:\\".$1."\\ \n";
}
elsif( /<version_num>608<\/version_num>/ ){
if($tasks{$WUname}){
if($tasks{$WUname} == 1){
print "VLAR on GPU: " . $WUname ."\n";}
elsif($tasks{$WUname} == 2){
print "VHAR on GPU: " . $WUname ."\n";}
}
}
}
close(IN);

print "Number of CPU tasks:".$NumOfCPUTasks."\n";
print "Number of GPU tasks:".$NumOfGPUTasks."\n";
print "Number of VLAR tasks:".$NumVLAR."\n";
print "Number of VHAR tasks:".$NumVHAR."\n";
if($NumOfCPUTasks!=0){ $GPU_to_CPU_ratio=$NumOfGPUTasks/$NumOfCPUTasks;}
else{ $GPU_to_CPU_ratio=1;}
if($GPU_to_CPU_ratio >$NumGPUToNumCPU_high_limit){
print "Too many tasks allocated to GPU already ".$GPU_to_CPU_ratio."\n";}
if($GPU_to_CPU_ratio <$NumGPUToNumCPU_low_limit){
print "Too many tasks allocated to CPU already " .$GPU_to_CPU_ratio ."\n";}
print "Total tasks: ".($NumOfCPUTasks+$NumOfGPUTasks)."\n";

Yup, if there were any VLAR or VHAR on the GPU it would spit out a line saying <WU name> VLAR on GPU. Since you have 223 on CPU and 196 VLAR/27 VHAR that means only VHAR and VLAR are on CPU, so no mid range ones that need to move either.

Yup, if there were any VLAR or VHAR on the GPU it would spit out a line saying <WU name> VLAR on GPU. Since you have 223 on CPU and 196 VLAR/27 VHAR that means only VHAR and VLAR are on CPU, so no mid range ones that need to move either.

i noticed a download and ran the script and it had a large amount of both vlar and vhar listed for the gpu. ran the V5 and it fixed it :) now all i have to do is figure out a way to run the script automatically.

it would be a really nice addition to have an option to have boinc run an external script after downloading before starting any new tasks. (i know dream on) :)

i hate cycling boinc often but since the downloads are asked for at random times it almost seems to minimize problems i should run a cron job once an hour that will stop boinc, run the V5 script and replace the old state file and then restart boinc..
____________

wonder if i should change the topic name? maybe to something like

2 devices in linux and keeping gpu free of hassles

or something :P


____________

What I've done is set mine to 10 days cache, wait until I have a bunch and then set the cache back to 5 days. Then I shut down, run the script, check to make sure it looks good (I have another modified one that will move back X VLAR or VHAR to the GPU if I think the CPU has too much work) and then restart it. Once I get down to a couple days work I'll put the cache back up and download more.

Right now I'm letting my cache clear so I can set my pflops right.

What I've done is set mine to 10 days cache, wait until I have a bunch and then set the cache back to 5 days. Then I shut down, run the script, check to make sure it looks good (I have another modified one that will move back X VLAR or VHAR to the GPU if I think the CPU has too much work) and then restart it. Once I get down to a couple days work I'll put the cache back up and download more.

Right now I'm letting my cache clear so I can set my pflops right.

We're looking good now. Steady work coming in (broke 7k RAC so far). Just upgraded to CUDA 2.3 and OC both my 260s.

Thu 30 Jul 2009 12:47:25 AM KST CUDA devices: GeForce GTX 260 (driver version 0, CUDA version 1.3, 895MB, est. 125GFLOPS), GeForce GTX 260 (driver version 0, CUDA version 1.3, 896MB, est. 121GFLOPS)

Couldn't get the 2nd card stable at the same clocks :(

Going to run tests for a bit more, but so far it looks good. Just need to confirm long term stability at these clocks.

We're looking good now. Steady work coming in (broke 7k RAC so far). Just upgraded to CUDA 2.3 and OC both my 260s.

Thu 30 Jul 2009 12:47:25 AM KST CUDA devices: GeForce GTX 260 (driver version 0, CUDA version 1.3, 895MB, est. 125GFLOPS), GeForce GTX 260 (driver version 0, CUDA version 1.3, 896MB, est. 121GFLOPS)

Couldn't get the 2nd card stable at the same clocks :(

Going to run tests for a bit more, but so far it looks good. Just need to confirm long term stability at these clocks.

Been going steady overnight, so think I've got it stable. Primary card has a core of 755Mhz, secondary couldn't handle that so it's at 725Mhz (I was too lazy to find the exact max for it).

I'm very happy with these clocks, think I'll stick with this company for my next purchase. Heat is still barely over what it was before, which strikes me as odd but I guess those coolers work well.

Been going steady overnight, so think I've got it stable. Primary card has a core of 755Mhz, secondary couldn't handle that so it's at 725Mhz (I was too lazy to find the exact max for it).

I'm very happy with these clocks, think I'll stick with this company for my next purchase. Heat is still barely over what it was before, which strikes me as odd but I guess those coolers work well.