Is it more of a driver issue (where we would have to wait for Nvidia to get their act together before there is any relief), the way that the Guppies are configured when they are split (something that can be addressed internally, though with the manpower crunch, is that likely anytime soon?), or something else that causes such a penalty for them on Nvidia hardware? Are things much better in the AMD world? I haven't ran a AMD card for probably 15+ years, so I basically have no experience with them.

I am crunching both SETI@home GPUs and SETI Beta GPUs on an AMD HD 7770 in my Linux box and they take about one hour or less even if they are VLAR.
Tullio

Hmmmm, are you running 2 at a time...or something?
My ATI 7750 runs them in under 30 minutes, http://setiathome.berkeley.edu/result.php?resultid=4932770085, which is better than the 6850s and about the same as the 150 watt 6870.
You might try adding some settings, try just the basic ones my 7750 is using;
-sbs 256 -oclfft_tune_gr 256 -oclfft_tune_wg 128

very short version:
low AR => longer time to stare at same point => bigger data array for single PoT search => failure to fit cache, failure to get enough parallel data to fill all CUs (longer single array = less number of such arrays cause 1M matrix of data point remains constant)

OK, this helps. Since slewing Arecibo work units don't do this, the AR must be greater than the scope's "aperture". Let's say that the AR is 3x the size of the aperture of the scope.

Then why not break the WU into that ratio of pieces (in this case 3) and run the pulsefind on each piece, then add the results? That way each piece being of the same timebase as an Arecibo Gaussian won't overload the cache.

Edit: This will take some tinkering due to pulses at the edge of each piece that and up in both of them...

---

No, I am a total novice on GPUs and run them one at a time, both on the Linux box with AMD and the Windows 10 PC with a GTX 750 Ti OC, which runs mostly Einstein@home tasks, which take much longer but reward me with 4400 credits.
Tullio

---

No, I am a total novice on GPUs and run them one at a time, both on the Linux box with AMD and the Windows 10 PC with a GTX 750 Ti OC, which runs mostly Einstein@home tasks, which take much longer but reward me with 4400 credits.
Tullio

Multiply 'Seti Time' and credits by ~3.3 +/- and you will get Einstein time :D

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I made a rule of thumb calculation. Einstein@home is giving me 900 credits/hour per elapsed time on a GPU task, while SETI@home gives me 100 credits/hour also on a GPU task. I am not crunching for credits, being a (retired ) physicist I am strongly interested in Einstein@home. Most of the Einstein projects use only CPUs, only the search for binary radio pulsars on Arecibo and Parkes data uses GPUs.
Tullio

---

Is that before, during, or after v8 transition, and does it factor that Guppi tasks are lower efficiency running ?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

From memory of my walk through of the credit code a few years back, and running some simulations, it would appear that the code is all but incapable of correctly resolving the sot of changes that have happened in the last few months. It struggles with the slow increase in performance of both computer and application, but when you have a step change in application and the type of work unit coming out it is all but incapable of working out what is going on. It will default to granting to the lowest possible credit for each task, which will result in a drop in credit granted for a "standard" of between 15 and 30%. Further this drop will continue for about another 5 to 10 % (of the initial credit).
As has been said by some for a long time CreditNew is far from "fit for purpose" - even if one assumed that the purpose is to allow comparison in performance between systems and applications within a project - it is far too dependent upon the performance of the individual computer, and NOT on the content of the task.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Works for me, so question is what do we do about it ?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

All my tasks are V8 now. guppi tasks take a little longer, but not much.
Tullio

---

All my tasks are V8 now. guppi tasks take a little longer, but not much.
Tullio

and credit is equal for equal work ?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Then why not break the WU into that ratio of pieces (in this case 3) and run the pulsefind on each piece, then add the results? That way each piece being of the same timebase as an Arecibo Gaussian won't overload the cache.

Well I skip any discussion about number 3 origin. But in essense it's the way to deal with too long arrays - to split them on subarrays where possible. This have own pluses and minuses: + less number of data point fit in smaller cache better,
+ more separate chains of data to load parallel device better, - need to assemble back, that is, additional synching between data parts processing.

Also, not always possible to select even loosely independend parts of data array.
Consider folding algorithm (in real MultiBeam PulseFind actual folding done also by 3 and 5 ) in its simpliess form (as it implemented in AstroPulse):
one need to take 2 numbers separated by "arbitrary" (in real life - computed from let say data recording params and wanted period to analyze) stride, add them and put in next array. Then repeat the same (and probably with different stride) on new array and so on [And, of course, check each iteration if we have smth over threshold and select best of them - another synching point in this reduction process]. To launch separate kernel for each cycle will be absolute performance kill. So one pass. Then one should know that global memory considered asynchronous between workitems in the same kernel. That is, if CU0 writes smth in cellN and CU1 reads from cellN - order of these operations undefined. So, when one try to split array onto parts one can have synching only inside workgroup (256 workitems for AMD, up to 2048 for modern NV). Obviously part of array that should be handled by single workgroup should be enough to include all data that constitute last point after folding. That limits ability of "divide and conquer" approach in this case.

All my tasks are V8 now. guppi tasks take a little longer, but not much.
Tullio

and credit is equal for equal work ?

Frankly I don't know. As I said, I am not interested in credits. I was rather surprised by the amount of credits given by Einstein@home to GPU tasks, which increased my RAC well above my usual standards in 6 or 7 BOINC projects.
Tullio

---

BTW, Einstein@home on CreditScrew currently?

BTW, Einstein@home on CreditScrew currently?

I believe Einstein@home uses fixed credit per app. All of my tasks have been the same credit for Binary Radio Pulsar Search (Arecibo, GPU) & Binary Radio Pulsar Search (Parkes PMPS XT).

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!

All my tasks are V8 now. guppi tasks take a little longer, but not much.
Tullio

and credit is equal for equal work ?

I dunno, but perhaps if someone could figure out Why CreditFew usually gives Double the credit to a GPU GUPPI when matched against another GPU than when matched against a CPU we might discover a nasty Bug. It has to be significant that the same GPU scores twice as high depending if it is matched against a GPU or a CPU. If the same score was given in both instances the credit for a GUPPI VLAR wouldn't be that bad providing you are using a recent App that runs them decently. Look at these results;
GPU vs CPU
http://setiathome.berkeley.edu/workunit.php?wuid=2159959167
http://setiathome.berkeley.edu/workunit.php?wuid=2159959173

GPU vs GPU
http://setiathome.berkeley.edu/workunit.php?wuid=2160605280
http://setiathome.berkeley.edu/workunit.php?wuid=2159519714
http://setiathome.berkeley.edu/workunit.php?wuid=2159519586

Of course some of them don't follow the pattern, and it does seem the highest scores are given to nVidia vs nVidia. Possibly it is just random numbers...

Now it seems the forum is kinda sluggish as well.

Works for me, so question is what do we do about it ?

Three answers:
1 - Nothing (preferred by DA as he won't collect any facial egg)
2 - Fixed credit per task type, simple only two values, one for MB and one for AP. The majority of BOINC projects are using this as they see CreditNew as being too difficult to configure correctly.
3 - Develop a task-based system that takes into account the nature of the task. I've been looking at one for MB tasks, and it is actually quite trivial to do - a simple function of AR. For APs the lack of suitable data is proving an obstacle, but I've got a couple of ideas.
Also the task error handling needs to be looked at, there is something "not right" with it just now, it should never give "full marks" to a task that ended early in an error state, but it does every now and then - I suspect it is tied up with the way CN uses the user run times to calculate the score, but I will need a bit more time to look and see what is going on it that snake pit of code.



*Did anyone ever mention that the CN code is somewhat convoluted in its structure. I've seen less tangled bowls of spaghetti....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Rather than edit my last post:

The advantage of both 2 & 3 is that they give a consistent score per task that is totally independent of the processor or application employed. Thus if one has a very fast processor your score per hour will be higher than a low end processor, also it will be a very simple to compare between the various optimised and non-optimised applications.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I personally would prefer that it be repaired, as it can and should be a useful barometer of how one's computers are running.

+1

---

Rather than edit my last post:

The advantage of both 2 & 3 is that they give a consistent score per task that is totally independent of the processor or application employed. Thus if one has a very fast processor your score per hour will be higher than a low end processor, also it will be a very simple to compare between the various optimised and non-optimised applications.

Now that I totally agree with.

Cheers.

As noted much elsewhere, they process much more slowly than Arecibo MBs but pay the same credit.

Not quite true, they take any where between 4x to 6x as long to complete and from what I have seen in the "valid" area you get about 2x the credit (if you are lucky), hence the nose dive.

---