Message boards :
Number crunching :
AP v7 Credit Impact
Message board moderation
Author | Message |
---|---|
Lionel Send message Joined: 25 Mar 00 Posts: 680 Credit: 563,640,304 RAC: 597 |
As some of you would have gathered, I implemented v7 on AP just after the WUs became available. At the time I noticed a significant drop in credit per WU but was prepared to wait and see what happened. The following is based solely on GPU data (in this case a pair of EVGA GTX770 SCs) To date, what I have noticed is that APv7 WUs are averaging around 2,834 seconds to complete compared to APv6 WUs that were taking circa 3,800 seconds to complete. APv6 WUs were being granted circa 650 credits per WU. The average credit being granted per APv7 WU is circa 265. Looking backwards, the breakeven point for v7 credits compared to v6 credits is circa 484 given the shorter processing time of v7 AP WUs. What I am seeing at the moment is a 45% reduction in granted credit for completing a v7 AP WU compared to a v6 AP WU. At present I cannot see any indication that things will improve significantly beyond this point (with only 7 out of the 200 latest v7 AP WUS cracking the 300 barrier). Also of note is that in looking at v7 MB WUs, the credit being granted is higher than for v7 AP WUs. The average processing time for a v7 MB WU is circa 715 seconds with average credit of 93. To put it another way, v7 AP WUs are currently running at an average of 0.93654 credits/second of processing time whilst v7 MB WUs are currently running at an average of 0.1303 credits per second of processing time. Unless things improve, I don't see v7 AP WUs being as desirable as v6 was going forward and the reverse effect of what people have been seeing over the last 12+ months between AP and MB will occur. I for one am considering not processing v7 AP WUs next time around and I think others will start thinking this way very soon after they see the impact on their RAC. cheers |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
It has been mentioned numerous times now of how the credit did the same thing at Beta. In fact it started out much lower at Beta than it here here on Main. Over time it ramped up to a average near the same as AP v6. If the credit is bothering you then perhaps you should only run MB until AP "pays" what you feel it should for your computing time? Or you could sit back and hold on for the ride like everyone else who isn't whining about it. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
betreger Send message Joined: 29 Jun 99 Posts: 11361 Credit: 29,581,041 RAC: 66 |
I for one am considering not processing v7 AP WUs next time around and I think others will start thinking this way very soon after they see the impact on their RAC. I rue the decling RAC but I feel the real reason to crunch here is to find "them" and I think the broadband search that AP does has a better chance. |
W-K 666 Send message Joined: 18 May 99 Posts: 19065 Credit: 40,757,560 RAC: 67 |
I everybody acted like you and aborted AP7 tasks then the credit will take forever to rise to the final value. Pretty b****y selfish in my books, but I guess there are lots of people like you that are actually only interested in credits. |
ExchangeMan Send message Joined: 9 Jan 00 Posts: 115 Credit: 157,719,104 RAC: 0 |
As some of you would have gathered, I implemented v7 on AP just after the WUs became available. At the time I noticed a significant drop in credit per WU but was prepared to wait and see what happened. Lionel, I agree with your diagnosis of the present credit granting behavior under V7 Astropulse. I did get 1 task that came in at 463 and was hoping things were starting to turn around, but to no avail. This APV7 is turning into the frustration we went through with MB V7. With the way things are going, running 100% MB V7 may end up paying the most credit - who would have thought. I've received quite a few of the AP V6 work units, but they won't last forever. Someone mentioned that this situation may autocorrect itself as more work units get returned - this was repeatedly stated with MB V7 and things didn't improve to where they should have. I need to see this for myself to believe it. Perhaps the powers that be will finally address the goofy credit granting scheme after AP V7 is fully rolled out. We can only hope. |
Wiggo Send message Joined: 24 Jan 00 Posts: 34768 Credit: 261,360,520 RAC: 489 |
Gee Lionel, I bet that you wish now that you didn't abort all that v7 MB work that you had before the last AP feeding? :-O Cheers. |
Lionel Send message Joined: 25 Mar 00 Posts: 680 Credit: 563,640,304 RAC: 597 |
... who isn't whining about it. HAL9000, I'm not whining about it, only pointing out my observations to date. It would appear to me that you and others are more sensitive about this than I could ever possible be. You may be right in that it will "ramp up" as you indicate but I cannot see any evidence of that emerging at present and I am of the view that others will come to this same opinion sooner or later. As to which WUs I process, I had already made my decision. I have set my preferences to v7 MB and v6 AP (as I have a few left and am just wishing to help out with their quick completion). |
Lionel Send message Joined: 25 Mar 00 Posts: 680 Credit: 563,640,304 RAC: 597 |
As some of you would have gathered, I implemented v7 on AP just after the WUs became available. At the time I noticed a significant drop in credit per WU but was prepared to wait and see what happened. ExchangeMan, I noticed a similar behaviour in that the early ones were circa 120 - 180 and that over time that rose (with some landing over 300) but what I see at the moment is a plateau effect occuring. If this plateau continues based on current trend then processing MB will become the norm for most crunchers in the future. re your second paragraph, I seem to recall something similar. cheers |
ExchangeMan Send message Joined: 9 Jan 00 Posts: 115 Credit: 157,719,104 RAC: 0 |
As some of you would have gathered, I implemented v7 on AP just after the WUs became available. At the time I noticed a significant drop in credit per WU but was prepared to wait and see what happened. Well, it'll just be a wait and see. I have had some work units over 300 btw. |
Lionel Send message Joined: 25 Mar 00 Posts: 680 Credit: 563,640,304 RAC: 597 |
Gee Lionel, I bet that you wish now that you didn't abort all that v7 MB work that you had before the last AP feeding? :-O Wiggo: No, not at all. I wanted to get an early indication of where v7 AP was going. As I have said prior, the early units received somewhere between 120 / 180 credits (that was for about a 45 minute run per WU). Over time that rose to where it is today (circa 280) and I am not seeing any further increase in credit/recognition for effort. At this point I cannot see any reason for preferring v7 AP over v7 MB. cheers |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Gee Lionel, I bet that you wish now that you didn't abort all that v7 MB work that you had before the last AP feeding? :-O Just a few points; The Slowest APv7 CPU tasks haven't even had a chance to finish. The main reason MBv7 suffered such a RAC drop was due to the GPU App being much Slower than MBv6. The APv7 GPU App is slightly faster than the APv6 App, hence, a similar RAC drop would not be expected. Due to the differences, MB & AP will never pay the same based solely on Math. If it is such an Issue, I suggest an external fudge factor be added to equalize them. I suggested this a while back, it wouldn't be difficult to implement. All it would take is to convince the right person(s). |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
The main reason MBv7 suffered such a RAC drop was due to the GPU App being much Slower than MBv6. Actually the main reason MBv7 dropped over v6 is because the baseline stock CPU application gained AVX (SIMD) functionality, but the peak flops figures used to scale the efficiencies use Boinc Whetstone, which is a serial FPU measure. For ratios Compare Boinc Whetstone, to Sisoft Sandra Lite FPU single thread Whetstone, then SSE-SSE2, and the AVX Single threaded bench. Then you have two dicrete credit drops, one during MB5-6, and the other with MB7. "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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
The main reason MBv7 suffered such a RAC drop was due to the GPU App being much Slower than MBv6. You're going to have to be more convincing than that. I have here example #1, an old NV8800 Veteran of the MB wars, http://setiathome.berkeley.edu/results.php?hostid=6813106 That Card ran a MBv6 Shorty in just over 4 minutes and netted in the low 30s. Now it takes over 16 minutes to complete the same Shorty. Pretty strong evidence if you ask me... |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
Gee Lionel, I bet that you wish now that you didn't abort all that v7 MB work that you had before the last AP feeding? :-O Eric has explain before that anything he would do to try in order to equalized the credit to where it was before would get revered by CreditNew. In theory it seems like it would be possible for someone to externally change the base credit. By settings up a large number of VM's and running the base stock app. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
The main reason MBv7 suffered such a RAC drop was due to the GPU App being much Slower than MBv6. A 'shorty' is no longer the same amount of work, since it contains autocorrelations, so not comparing apples with apples. Shorties, as with other angle ranges of course, should have received more credit, rather than less, due to the added work. 'Correct' Credit award for a MB7 VHAR, according to the Cobblestone scale, is ~90+ Credits. There are certainly inefficiencies in the autocorrelation implementation, however the artefacts dominant are from the application used for credit normalisation, which is CPU stock by a factor of ~3.3x effective underclaim. Fixing that gives you back half your MB7 effective drop, then some bonus for the drop that preceeded GPU implementations. Future optimisations may provide some improvement also, though the options are dwindling for that particular generation of GPU as well, which struggle with the required large Fourier transforms. "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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Gee Lionel, I bet that you wish now that you didn't abort all that v7 MB work that you had before the last AP feeding? :-O I went over this with Jason a while back. All you would have to do is work outside of CreditFew with an EXTERNAL Correction. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Eric has explain before that anything he would do to try in order to equalized the credit to where it was before would get revered by CreditNew. Yeah, a lot of back and forward has been happening. The consensus working with Albert on the issue, and occasional input from Eric, has been there are a number of key issues, not least being improper use of averages and quite a lot of spaghetti code that needs a trasnsplant. (validator and scheduler) "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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
The main reason MBv7 suffered such a RAC drop was due to the GPU App being much Slower than MBv6. The simple fact is, it is taking Much longer on the same Hardware to gain the same credits as with MBv6. That is Not the case with APv7. The same task is slightly faster than with APv6. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
up a large number of VM's and running the base stock app. Basically yes. Bernd (from Albert) has mentioned being in favour of a full gut and do over, While Oliver's recommended (which I agree with) manageable subproblems need to be tackled. Drawing dividing lines and planning to deal with the spaghettification factor is where things are at, and ground to a crawl, so larger highly modular mechanism transplants seem likely at this point. "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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
The simple fact is, it is taking Much longer on the same Hardware to gain the same credits as with MBv6. That is Not the case with APv7. The same task is slightly faster than with APv6. Correct. AVv7 has less processing than v6 (simpler blanking). [Edit:] blanking was always unpaid overhead though. Going from rough memory, AP credit (v6 or V7) should really be ~1000 credits, but I predict will probably settle in the region of 300-400 credits, with substantial variance. "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. |
©2024 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.