20101216, 12:59  #1 
Jun 2003
2221_{8} Posts 
Insufficient information for accurate CPU credit.
I just submitted the following two factors via the manual testing form:
Code:
[Fri Nov 26 10:38:45 2010] P1 found a factor in stage #1, B1=515000. UID: daran/cuica, M42785489 has a factor: 340930634243704316351, AID: 4B29AFF5F9D1EB7A3C61A9B9118851B9 [Thu Dec 16 08:06:37 2010] P1 found a factor in stage #1, B1=465000. UID: daran/cuica, M39394703 has a factor: 51759351545613783550417, AID: 460389DCB57262419281C8E7E4C6AD36 Code:
No factor lines found: 0 Mfaktc no factor lines found: 0 Factors found: 2 Processing result: M42785489 has a factor: 340930634243704316351, AID: 4B29AFF5F9D1EB7A3C61A9B9118851B9 Insufficient information for accurate CPU credit. For stats purposes, assuming factor was found using P1 with B1 = 800000. CPU credit is 2.0139 GHzdays. Processing result: M39394703 has a factor: 51759351545613783550417, AID: 460389DCB57262419281C8E7E4C6AD36 Insufficient information for accurate CPU credit. For stats purposes, assuming factor was found using P1 with B1 = 800000. CPU credit is 1.5273 GHzdays. P1 lines found: 0 LL lines found: 0 Mlucas lines found: 0 Glucas (G29) lines found: 0 Glucas lines found: 0 MacLucasFFTW lines found: 0 CUDALucas lines found: 0 ECM lines found: 0 
20101217, 01:16  #2  
"Richard B. Woods"
Aug 2002
Wisconsin USA
2^{2}×3×641 Posts 
Quote:
Quote:
IIRC (it's been a while since I did this, and I can't find a saved example) the automatic report text to PrimeNet does not include the actual B1/B2 when reporting a factor. So, PrimeNet can't calculate credit on that basis, but it generates a B1 based on some formula. Your manual report included B1(/B2), but PrimeNet is ignoring that and performing the credit calculation without actual B1/B2, but generating a B1 based on that same formula, just as it does for the automatic reports. Last fiddled with by cheesehead on 20101217 at 01:19 

20101217, 01:53  #3  
Jun 2003
3^{2}·19·29 Posts 
Quote:


20101217, 02:14  #4  
Jun 2003
7×167 Posts 
Quote:
Quote:
Code:
cuica 39046153 NFPM1 20100808 17:19 93.7 B1=465000, B2=12090000 2.0970 cuica 39008107 NFPM1 20100808 17:19 28.8 B1=465000, B2=12090000 2.0970 cuica 39008779 FPM1 20100808 17:19 28.8 6397283804036361597329 2.0970 cuica 39968749 NFPM1 20100808 17:19 0.0 B1=480000, B2=12360000 2.8377 cuica 39973847 NFPM1 20100805 07:41 90.3 B1=480000, B2=12360000 2.8377 cuica 39973279 FPM1 20100804 23:14 90.0 4632811025542760339833 1.2083 cuica 39007921 NFPM1 20100804 07:11 24.3 B1=465000, B2=11857500 2.0728 cuica 39969173 NFPM1 20100803 15:10 88.6 B1=480000, B2=12360000 2.8377 cuica 39965917 NFPM1 20100801 11:53 86.5 B1=480000, B2=12360000 2.8377 cuica 39015863 NFPM1 20100712 08:26 66.3 B1=465000, B2=12090000 2.0970 cuica 39012313 NFPM1 20100711 14:26 65.6 B1=465000, B2=12090000 2.0970 cuica 39010459 FPM1 20100710 18:58 64.8 1097229813650567416577 2.2539 cuica 39010901 NFPM1 20100709 22:18 63.9 B1=465000, B2=12090000 2.0970 cuica 39011341 NFPM1 20100708 23:50 63.0 B1=465000, B2=11857500 2.0728 cuica 39010603 NFPM1 20100708 06:23 62.2 B1=465000, B2=11857500 2.0728 cuica 39740093 FPM1 20100707 12:33 21.1 218423414608878788302287871 2.8081 cuica 39737561 NFPM1 20100706 12:02 20.1 B1=475000, B2=12231250 2.8081 cuica 39009119 NFPM1 20100705 12:13 19.1 B1=465000, B2=11857500 2.0728 cuica 39691237 NFPM1 20100704 18:12 18.3 B1=475000, B2=12231250 2.8081 cuica 39682717 FPM1 20100703 18:32 17.3 624302998170670921801 1.1957 cuica 40420057 NFPM1 20100703 16:18 56.6 B1=455000, B2=10806250 2.5651 cuica 39007183 NFPM1 20100702 16:28 16.2 B1=465000, B2=12090000 2.0970 cuica 39005611 NFPM1 20100701 20:12 15.4 B1=465000, B2=12090000 2.0970 cuica 38988233 NFPM1 20100701 00:43 14.6 B1=465000, B2=12090000 2.0970 cuica 39007219 NFPM1 20100630 05:15 13.8 B1=465000, B2=12090000 2.0970 The one anomaly is the 7/10 factor, whose credit is not matched or even close to any other result, successful or not, in the past year. The most likely explanation is that this exponent was assigned with a much lower TF level, and consequently was P1ed. to higher bounds. In the case of my manual reports, the server did compute its own bound, one that it considerably at odds with the bounds typically used for exponents of this size: 

20101217, 02:23  #5  
Jun 2003
7·167 Posts 
Quote:
It's not unreasonable for Primenet to ignore the bounds in manual reports, regardless of where they appear, on the grounds that they're easily forged. That said, the current system is open to abuse: I could submit all my stage 1 factors manually to gain extra credit, while allowing my stage 2 factors to be reported in the normal way. 

20101217, 03:49  #6  
Jun 2003
3^{2}×19×29 Posts 
Quote:


20101217, 20:29  #7 
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
17×251 Posts 
Assuming everything works just like the one test I just did (with 400 MB allowed; and I'm sure it doesn't work perfectly the same, but probably close enough for these purposes), and Prime95's "Chance of finding a factor..." is accurate, and the difference between (expected factors in stage 1)/(expected factors total) is not significantly different from (chance of factor in stage 1)/(chance of factor total) about 47% of P1 factors in twostage tests are found by stage 1. But still, P1 factors are rare enough, and the difference in credit small enough, that if you abused this to the maximum potential, you'd probably only get about 1.2% more credit on average than you deserve.

20101217, 21:56  #8  
Nov 2010
Germany
597_{10} Posts 
Quote:
Quote:
And this is even worse when finding a factor in ECM: Quote:
Quote:
Maybe it's time to improve the manual reporting to not ignore the lines before the "has a factor" one? The information for accurate accounting is there ... 

20101217, 22:09  #9 
Jun 2003
11537_{8} Posts 

20101217, 22:15  #10  
Jun 2003
3^{2}·19·29 Posts 
Quote:
*Find the largest factor of p1. Set my B1 = that factor  1. Then set B2 = 10000 * that factor. For eg: 91256242231171376858471 = 2*3*13*109*5392193*199056357361 Set B1 = 199056357360 and B2 = 1990563573600000. Watch the credits roll in 

20101218, 03:41  #11 
"Richard B. Woods"
Aug 2002
Wisconsin USA
2^{2}×3×641 Posts 
Thanks for the correction. Now I can recall the time when I (automatically) sent multiple closelyspacedB1 reports for an exponent, and as a result got way, way more credit than deserved because each credit assumed I had started at zero.

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Insufficient Information for accurate CPU Credit  TheMawn  GPU Computing  4  20140607 20:52 
Account Information  Primeinator  Information & Answers  13  20111203 19:42 
Insufficient information for accurate CPU credit  Yura  Information & Answers  11  20110622 11:52 
Program information use  Unregistered  Information & Answers  0  20090830 19:03 
Is More Information Better?  davar55  Puzzles  3  20090702 20:25 