SETI MB CUDA for Linux

[Richard Haselgrove]

interesting... doesnt look like i will have the large increase you did but my rac went down by about 100 points but my pending went up by almost 300 points.. wonder why pending increases when running more aggressively?

Because you complete them faster than your wingmate.

Typically, when testing new builds, you start with an empty cache (at least that's the way you should do it). So the run starts quickly. And if the build is any good, it'll finish quicker too .

[pp]

Interesting ...
Here's the output.

Code: [Select]

CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y                                       
CONFIG_SLUB_DEBUG=y
<snip>

I was looking for CONFIG_USB_STORAGE_DEBUG in particular but you don't seem to have it enabled. It's a huge performance killer. Don't really know about the others but personally I disable all debug options in my kernels after my encounter with the dreaded USB_STORAGE_DEBUG...

[riofl]

interesting... doesnt look like i will have the large increase you did but my rac went down by about 100 points but my pending went up by almost 300 points.. wonder why pending increases when running more aggressively?

Because you complete them faster than your wingmate.

Typically, when testing new builds, you start with an empty cache (at least that's the way you should do it). So the run starts quickly. And if the build is any good, it'll finish quicker too .

ahh ok.... makes sense.

[lordvader]

You should now be able to see a bunch of completed tasks under my valid units :

http://setiathome.berkeley.edu/results.php?hostid=5015908&offset=0&show_names=0&state=3

[lordvader]

Quick update.

I've just started trying a compiled kernel (2.6.31.5), and this time, I disabled all the debug AND disable x86 PAT support.

Without the script, units take a while, but with priority set to 0, they are basically up to speed (well, they average 13 minutes, can't recall if these units ran at 13 mins, or 6 mins though).

[sunu]

Looking at your tasks I see most from 3 Nov with bad times and from 4 Nov some with bad and some with good times. How were all these tasks run? Kernel, script on/off.

[lordvader]

All these were run with the script on.

The ones with bad times were from the stock Kubuntu 9.10 kernel. The ones with good times are from the kernel I compiled with x86 PAT disabled, and all debug turned off.

[sunu]

The ones with bad times were from the stock Kubuntu 9.10 kernel.

All those debug flags you posted above were from a stock "official" ubuntu kernel? 

[riofl]

odd... with the gpus running at 0 nicelevel, there is hardly any difference in times, typically around 29 min, but now i do see some around 26 to 27 min, but my pending has jumped by about 4000. typically my rac is a few hundred lower than normal. odd how this stuff behaves

[riofl]

are they still supplying larger workunits? i remember a few months ago my average was 11 to 13 min consistantly, now its averaging 28 to 29 min consistantly.

[sunu]

are they still supplying larger workunits? i remember a few months ago my average was 11 to 13 min consistantly, now its averaging 28 to 29 min consistantly.

All of them are "large". Only the VHARs are quite short.

[riofl]

wow 6.10.17 is nice! it not only recognizes the proper cuda devices reporting 1 per line like it should, but it also reports what device is being fed what workunit!! very nice!

now if the website would just accept the proper device list..........

[riofl]

WHOAH

did ya hear what happened to NEZ (one of the top seti participants)?


http://www.kpho.com/news/21778774/detail.html

[Gecko_R7]

Holy €^#!  Nez has a serious problem!

[riofl]

if that gets air time or spread nationally you can bet other organizations are gonna begin looking reallly hard at what their admins are doing. we may wind up losing a few  more since it is so easy to hide unless it is looked for.