Forum > Linux
SETI MB CUDA for Linux
riofl:
well we shall see. i compiled 6.9.0 and it properly uses the 2 devices but the reporting is broken. it tells me in the msg log that i have 2 teslas. i have not looked at the code at all but it seems to me that the devices would be kept in an array and it should be a very simple thing to transverse the array reporting the proper string in each. seems like the index is broken. minor issue but i would think it would only take a few seconds for someone familiar with the code to fix that.
the message log also states it cannot load library libcal.so. too late tonight but ill look to see if it is supposed to be created by the boinc make and try to track down what happened. if not then i dont know where it comes from.
boincmgr would not compile for me so im still using 6.6.37 manager but it works.
if it continues to work like it has in the past 5 min it will be nice to run a new version for a change :)
riofl:
hmm either that libcal has something to do with workunit calculations or i just got an entire cache full of big units. not one time is under 2:45 and watching boinc process it is EXTREMELY slow both on the cpus and gpus. system load and all other things are normal. unless since 6.6.11 calculations were severely broken that it will take a while for this version to fix that up and get it right. dunno. will see what it looks like in the morning.
sunu:
Yes, trunk is the one to get.
What boinc reports is a minor cosmetic bug. The important thing is to use all gpus properly.
libcal.so is for ATI cards (something like libcudart.so for NVIDIA cards). ATI card support was added a couple of days ago for milkyway@home. It should be irrelevant to us.
I've never bothered with boincmgr while compiling from source. I use the released ones. As long as boinc works properly, we're ok.
Lately there was an increase in sensitivity so most of the recent workunits are big ones. In my pc they take about 12-15 min for the gpu and about 1:45-2:00 hours for the cpu. Boinc doesn't have anything to do with the speed of computations, unless it uses 100% of the CPU slowing things down.
riofl:
--- Quote from: sunu on 16 Aug 2009, 05:11:30 am ---Yes, trunk is the one to get.
What boinc reports is a minor cosmetic bug. The important thing is to use all gpus properly.
libcal.so is for ATI cards (something like libcudart.so for NVIDIA cards). ATI card support was added a couple of days ago for milkyway@home. It should be irrelevant to us.
I've never bothered with boincmgr while compiling from source. I use the released ones. As long as boinc works properly, we're ok.
Lately there was an increase in sensitivity so most of the recent workunits are big ones. In my pc they take about 12-15 min for the gpu and about 1:45-2:00 hours for the cpu. Boinc doesn't have anything to do with the speed of computations, unless it uses 100% of the CPU slowing things down.
--- End quote ---
was concerned since previously i have never had a cuda work unit take more than 15min to process with typical 9 to 13 min, they are now taking approx 30 min for each card. and my rac has dropped for this machine by more than 400 points. ill just keep plugging away for a while to let things settle out. nothing was changed in the 'backend' applications so it must be the larger workunits presented.
overall boinc seems to be managing things nicely. it no longer keeps a backlog of completed units to report which is refreshing.
sunu:
--- Quote from: riofl on 16 Aug 2009, 06:38:19 am ---was concerned since previously i have never had a cuda work unit take more than 15min to process with typical 9 to 13 min, they are now taking approx 30 min for each card. and my rac has dropped for this machine by more than 400 points. ill just keep plugging away for a while to let things settle out. nothing was changed in the 'backend' applications so it must be the larger workunits presented.
--- End quote ---
No,,this is not good. Check how boinc handles the tasks. When a cuda workunit finishes, does it also stop the other one running to start a new pair?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version