mersenneforum.org Primenet doesn't like mfaktc !
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2012-11-15, 16:13 #1 Antonio     "Antonio Key" Sep 2011 UK 32·59 Posts Primenet doesn't like mfaktc ! I submitted the following today:- [Thu Nov 15 14:26:56 2012] UID: antonio***/MeshGT, M60034333 has a factor: 2367021681159838675897 [TF:71:72:mfaktc 0.19 barrett76_mul32] [Thu Nov 15 14:42:40 2012] UID: antonio***/MeshGT, found 1 factor for M60034333 from 2^71 to 2^72 [mfaktc 0.19 barrett76_mul32] And Primenet responded with:- No factor lines found: 0 Mfaktc no factor lines found: 0 Mfakto no factor lines found: 0 Factors found: 1 Processing result: M60034333 has a factor: 2367021681159838675897 Insufficient information for accurate CPU credit. For stats purposes, assuming factor was found using P-1 with B1 = 800000. CPU credit is 2.9322 GHz-days. P-1 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 Any ideas as to why Mfaktc was not recognised?
2012-11-15, 16:57   #2
chalsall
If I May

"Chris Halsall"
Sep 2002

7·1,361 Posts

Quote:
 Originally Posted by Antonio Any ideas as to why Mfaktc was not recognised?
This is a known bug with the PrimeNet manual submission parcer. It doesn't "see" the "[TF:71:72:mfaktc 0.19 barrett76_mul32]" part of the "has a factor" line, and because the factor is larger than what Prime95/mprime usually go to, it assumes the factor was found via P-1.

Apparently, if you place a "no factor found" line done by mfakt[c|o] before any "has a factor" lines, the parcer will correctly attribute the work as being TF. I have been told (from reliable sources) that this can include any "no factor found" line, even one that which has already been submitted. Primenet will report "result not needed" for it, but will then correctly interpret subsequent factors correctly.

 2012-11-15, 17:04 #3 Antonio     "Antonio Key" Sep 2011 UK 32·59 Posts Thanks for the info. I seem to remember reading about it, now that you jogged my memory.... I think old age is getting to me!
 2012-11-15, 18:17 #4 kladner     "Kieren" Jul 2011 In My Own Galaxy! 2×3×1,693 Posts The "insufficient information" message suggests that the result was submitted without the second line of a Factor Found. I have run into this when I grabbed a result as soon as it appeared, but before the second line was written. Depending on your setting for "Stages" and "Stop after factor" in mfaktc.ini you might see something like this- Code: M59768411 has a factor: 5862553667819473936721 [TF:72:73*:mfaktc 0.19 barrett76_mul32] found 1 factor for M59768411 from 2^72 to 2^73 (partially tested) [mfaktc 0.19 barrett76_mul32] The above is what you will get with Stages=0, and StopAfterFactor=2. Note the (partially tested) entry. There is no penalty as I understand for stopping after a single factor is found. Some people just prefer to see if there are other factors. Stages=0 is said to be slightly more efficient than Stages=1. The line beginning "found 1 factor....." is necessary to receive proper credit. Last fiddled with by kladner on 2012-11-15 at 18:17 Reason: typo
2012-11-15, 19:06   #5
Antonio

"Antonio Key"
Sep 2011
UK

10238 Posts

Quote:
 Originally Posted by kladner There is no penalty as I understand for stopping after a single factor is found. Some people just prefer to see if there are other factors. Stages=0 is said to be slightly more efficient than Stages=1.
From previous experience, the penalty is a reduced GHzD credit to your account if you don't complete the bit range in which the factor is found.

2012-11-15, 19:15   #6
chalsall
If I May

"Chris Halsall"
Sep 2002

7·1,361 Posts

Quote:
 Originally Posted by Antonio From previous experience, the penalty is a reduced GHzD credit to your account if you don't complete the bit range in which the factor is found.
Incorrect.

George, and Primenet, only care about Primes.

2012-11-15, 19:17   #7

"Kieren"
Jul 2011
In My Own Galaxy!

2×3×1,693 Posts

Quote:
 Originally Posted by Antonio From previous experience, the penalty is a reduced GHzD credit to your account if you don't complete the bit range in which the factor is found.
OK. Sorry. It would not be the first time I've been mistaken. That's just how I run, in imitation of high-powered workers like Nucleon.

2012-11-15, 19:45   #8
chappy

"Jeff"
Feb 2012
St. Louis, Missouri, USA

48516 Posts

Quote:
 Originally Posted by kladner OK. Sorry. It would not be the first time I've been mistaken. That's just how I run, in imitation of high-powered workers like Nucleon.
Nucleon Light: The Choice of a New Iteration

20% of the taste with only half the kilocalories of waste heat.

 2012-11-15, 20:14 #9 swl551     Aug 2012 New Hampshire 23·101 Posts F.Y.I. Information on this condition was provided to me by kladner and flashjh a few weeks back and MISFIT's uploader was modified (in 1.6) to reorder the upload payload if the first row in the file was not a "no factor for" row. If no "no factor for" rows were available for export the export was cancelled. (includes manual and automated results uploading)
2012-11-15, 21:57   #10
Antonio

"Antonio Key"
Sep 2011
UK

32×59 Posts

Quote:
 Originally Posted by chalsall Incorrect. George, and Primenet, only care about Primes.
In that case, how do you explain the following results from my Primenet results page:-

This one was terminated at the end of the bit level:
Manual testing
72153259
F
2012-09-27 15:48
0.0
2260168474230693217897
6.4168 GHzD credit

This one was terminated when the factor was found:
Manual testing
72152867
F
2012-09-27 04:56
0.5
613405639091112789161
1.7464 GHzD credit

It certainly looks to me like a penalty for stopping early!

 2012-11-15, 22:10 #11 sdbardwick     Aug 2002 North San Diego County 2·11·31 Posts 69 bit factors should get 1/4ish of credit of 71 bit factors

 Similar Threads Thread Thread Starter Forum Replies Last Post mattmill30 PrimeNet 6 2016-02-05 19:52 Syntony PrimeNet 6 2014-10-23 00:23 jasong jasong 6 2014-02-12 14:15 kolen Information & Answers 5 2013-06-02 20:31 sonjohan GPU Computing 11 2012-01-27 15:10

All times are UTC. The time now is 15:39.

Sat Apr 17 15:39:58 UTC 2021 up 9 days, 10:20, 1 user, load averages: 1.60, 1.58, 1.52