AP v7 Credit Impact

Message boards : Number crunching : AP v7 Credit Impact
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1586016 - Posted: 13 Oct 2014, 0:36:17 UTC

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
ID: 1586016 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1586021 - Posted: 13 Oct 2014, 0:55:48 UTC

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[
ID: 1586021 · Report as offensive
Profile betreger Project Donor
Avatar

Send message
Joined: 29 Jun 99
Posts: 11359
Credit: 29,581,041
RAC: 66
United States
Message 1586023 - Posted: 13 Oct 2014, 1:05:58 UTC - in response to Message 1586016.  
Last modified: 13 Oct 2014, 1:07:49 UTC

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.
ID: 1586023 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 19012
Credit: 40,757,560
RAC: 67
United Kingdom
Message 1586029 - Posted: 13 Oct 2014, 1:28:07 UTC

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.
ID: 1586029 · Report as offensive
ExchangeMan
Volunteer tester

Send message
Joined: 9 Jan 00
Posts: 115
Credit: 157,719,104
RAC: 0
United States
Message 1586031 - Posted: 13 Oct 2014, 1:32:45 UTC - in response to Message 1586016.  

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

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

Send message
Joined: 24 Jan 00
Posts: 34744
Credit: 261,360,520
RAC: 489
Australia
Message 1586032 - Posted: 13 Oct 2014, 1:34:57 UTC

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

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1586034 - Posted: 13 Oct 2014, 1:46:59 UTC - in response to Message 1586021.  

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

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1586035 - Posted: 13 Oct 2014, 1:55:33 UTC - in response to Message 1586031.  

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

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.



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
ID: 1586035 · Report as offensive
ExchangeMan
Volunteer tester

Send message
Joined: 9 Jan 00
Posts: 115
Credit: 157,719,104
RAC: 0
United States
Message 1586036 - Posted: 13 Oct 2014, 2:02:49 UTC - in response to Message 1586035.  

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

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.



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

Well, it'll just be a wait and see. I have had some work units over 300 btw.
ID: 1586036 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1586037 - Posted: 13 Oct 2014, 2:03:51 UTC - in response to Message 1586032.  
Last modified: 13 Oct 2014, 2:07:45 UTC

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.


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

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1586040 - Posted: 13 Oct 2014, 2:26:03 UTC - in response to Message 1586037.  

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.


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

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).
ID: 1586040 · 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 1586042 - Posted: 13 Oct 2014, 2:31:44 UTC - in response to Message 1586040.  
Last modified: 13 Oct 2014, 2:33:01 UTC

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

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1586043 - Posted: 13 Oct 2014, 2:39:52 UTC - in response to Message 1586042.  

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.

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...
ID: 1586043 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1586046 - Posted: 13 Oct 2014, 2:55:17 UTC - in response to Message 1586040.  

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.


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

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).

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[
ID: 1586046 · 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 1586047 - Posted: 13 Oct 2014, 2:55:50 UTC - in response to Message 1586043.  
Last modified: 13 Oct 2014, 2:58:51 UTC

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.

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...


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

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1586049 - Posted: 13 Oct 2014, 3:04:46 UTC - in response to Message 1586046.  

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.


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

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).

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.

I went over this with Jason a while back. All you would have to do is work outside of CreditFew with an EXTERNAL Correction.
ID: 1586049 · 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 1586050 - Posted: 13 Oct 2014, 3:05:57 UTC - in response to Message 1586046.  

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.


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

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1586051 - Posted: 13 Oct 2014, 3:07:48 UTC - in response to Message 1586047.  

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.

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...


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.

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.
ID: 1586051 · 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 1586052 - Posted: 13 Oct 2014, 3:09:53 UTC - in response to Message 1586049.  
Last modified: 13 Oct 2014, 3:12:10 UTC

up a large number of VM's and running the base stock app.

I went over this with Jason a while back. All you would have to do is work outside of CreditFew with an EXTERNAL Correction.


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.
ID: 1586052 · 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 1586053 - Posted: 13 Oct 2014, 3:11:46 UTC - in response to Message 1586051.  
Last modified: 13 Oct 2014, 3:20:19 UTC

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.
ID: 1586053 · Report as offensive
1 · 2 · Next

Message boards : Number crunching : AP v7 Credit Impact


 
©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.