Average Credit Decreasing?

Message boards : Number crunching : Average Credit Decreasing?
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 15 · 16 · 17 · 18 · 19 · 20 · 21 . . . 33 · Next

AuthorMessage
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1787919 - Posted: 16 May 2016, 17:20:14 UTC - in response to Message 1787898.  

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
ID: 1787919 · Report as offensive
Profile Mr. Kevvy Crowdfunding Project Donor*Special Project $250 donor
Volunteer moderator
Volunteer tester
Avatar

Send message
Joined: 15 May 99
Posts: 3425
Credit: 1,114,826,392
RAC: 3,319
Canada
Message 1787922 - Posted: 16 May 2016, 17:30:01 UTC - in response to Message 1787909.  
Last modified: 16 May 2016, 17:39:19 UTC

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...
ID: 1787922 · Report as offensive
Profile tullio
Volunteer tester

Send message
Joined: 9 Apr 04
Posts: 8634
Credit: 2,930,782
RAC: 1
Italy
Message 1787923 - Posted: 16 May 2016, 17:34:22 UTC - in response to Message 1787919.  

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
ID: 1787923 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1787927 - Posted: 16 May 2016, 17:39:56 UTC - in response to Message 1787923.  

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.
ID: 1787927 · Report as offensive
Profile tullio
Volunteer tester

Send message
Joined: 9 Apr 04
Posts: 8634
Credit: 2,930,782
RAC: 1
Italy
Message 1787931 - Posted: 16 May 2016, 17:57:01 UTC - in response to Message 1787927.  

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
ID: 1787931 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1787932 - Posted: 16 May 2016, 18:00:30 UTC - in response to Message 1787931.  

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.
ID: 1787932 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 20782
Credit: 416,307,556
RAC: 380
United Kingdom
Message 1787940 - Posted: 16 May 2016, 18:14:13 UTC

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?
ID: 1787940 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1787943 - Posted: 16 May 2016, 18:22:46 UTC - in response to Message 1787940.  

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.
ID: 1787943 · Report as offensive
Profile tullio
Volunteer tester

Send message
Joined: 9 Apr 04
Posts: 8634
Credit: 2,930,782
RAC: 1
Italy
Message 1787944 - Posted: 16 May 2016, 18:25:04 UTC - in response to Message 1787932.  

All my tasks are V8 now. guppi tasks take a little longer, but not much.
Tullio
ID: 1787944 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1787945 - Posted: 16 May 2016, 18:29:30 UTC - in response to Message 1787944.  

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.
ID: 1787945 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6324
Credit: 106,370,077
RAC: 121
Russia
Message 1787946 - Posted: 16 May 2016, 18:35:34 UTC - in response to Message 1787922.  
Last modified: 16 May 2016, 18:42:38 UTC


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.
ID: 1787946 · Report as offensive
Profile tullio
Volunteer tester

Send message
Joined: 9 Apr 04
Posts: 8634
Credit: 2,930,782
RAC: 1
Italy
Message 1787952 - Posted: 16 May 2016, 18:43:45 UTC - in response to Message 1787945.  
Last modified: 16 May 2016, 18:44:10 UTC

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
ID: 1787952 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6324
Credit: 106,370,077
RAC: 121
Russia
Message 1787954 - Posted: 16 May 2016, 18:45:34 UTC - in response to Message 1787952.  
Last modified: 16 May 2016, 18:45:56 UTC

BTW, Einstein@home on CreditScrew currently?
ID: 1787954 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6533
Credit: 196,805,888
RAC: 57
United States
Message 1787955 - Posted: 16 May 2016, 18:47:17 UTC - in response to Message 1787954.  
Last modified: 16 May 2016, 18:48:44 UTC

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!
ID: 1787955 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1787960 - Posted: 16 May 2016, 19:15:30 UTC - in response to Message 1787945.  

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.
ID: 1787960 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 20782
Credit: 416,307,556
RAC: 380
United Kingdom
Message 1787980 - Posted: 16 May 2016, 21:23:01 UTC - in response to Message 1787943.  

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?
ID: 1787980 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 20782
Credit: 416,307,556
RAC: 380
United Kingdom
Message 1787983 - Posted: 16 May 2016, 21:28:12 UTC

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?
ID: 1787983 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1787990 - Posted: 16 May 2016, 21:52:32 UTC - in response to Message 1787874.  


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
ID: 1787990 · Report as offensive
Profile Wiggo
Avatar

Send message
Joined: 24 Jan 00
Posts: 26225
Credit: 261,360,520
RAC: 489
Australia
Message 1787992 - Posted: 16 May 2016, 21:54:40 UTC - in response to Message 1787983.  

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.
ID: 1787992 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1787993 - Posted: 16 May 2016, 21:57:26 UTC - in response to Message 1787881.  
Last modified: 16 May 2016, 22:09:50 UTC

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.
ID: 1787993 · Report as offensive
Previous · 1 . . . 15 · 16 · 17 · 18 · 19 · 20 · 21 . . . 33 · Next

Message boards : Number crunching : Average Credit Decreasing?


 
©2022 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.