mersenneforum.org Prime95 suspect credit for extended assignment arrangements broken?
 Register FAQ Search Today's Posts Mark Forums Read

 2014-04-10, 10:46 #1 snme2pm1   "Graham uses ISO 8601" Mar 2014 AU, Sydney 241 Posts Prime95 suspect credit for extended assignment arrangements broken? Using Prime95 v27.9 build 1 Contrast: 118300027: assigned and extended to be from 66 to 68 118300027: TF 66 to 67 credit 0.1263 118300927: TF 67 to 68 credit 0.2527 These were lodged manually after Prime95 failed to properly lodge results subsequent to restarted communication for results from my ancient space-heater G0 machine mid-course of that exercise. I guess a funny state existed. Versus: So now the Prime95 configuration of this G0 machine should be properly submitting results I would expect, however: 118300069: assigned and extended to be from 66 to 68 118300069: TF 66 to 67 interim result no factor 118300069: TF 67 to 68 factor after 85% progress, Prime95 lodged with credit 0.1087. I don't understand the arithmetic, it does not appear to add up reasonably. The 118300069 interim result from 66 to 67 would have worth about 0.1263 alone, aside from the 85% traversal of the 67 to 68 bit region. Whilst I don't expect my old space-heater to do much serious work, I thought that some otherwise idle time might be utilised, and this apparent problem might need attention. It is autumn in this part of the world so I don't mind my old G0 keeping me warm! Perhaps this an unfortunate side-effect of recent TF credit arrangements server side. But what is the real problem here? Is there a lingering issue with multiple level results by manual submission, or is there an issue isolated to Prime95 submission?
 2014-04-10, 23:45 #2 snme2pm1   "Graham uses ISO 8601" Mar 2014 AU, Sydney 241 Posts I suppose the short answer is that prime95 worktodo factor lines shouldn't be messed with. It seems willing to execute the extra work, but doesn't claim corresponding credit.
 2014-04-11, 04:10 #3 kladner     "Kieren" Jul 2011 In My Own Galaxy! 22·3·72·17 Posts Aren't those factoring levels of that range fairly short assignments to process? I have no experience with TF on a CPU, but even a modest GPU would dispose of those very quickly. I can't say if the credits are out of line. I've never worked in that range.
2014-04-11, 04:46   #4
LaurV
Romulan Interpreter

Jun 2011
Thailand

22·7·317 Posts

Quote:
 Originally Posted by snme2pm1 118300069: TF 66 to 67 interim result no factor 118300069: TF 67 to 68 factor after 85% progress, Prime95 lodged with credit 0.1087. I don't understand the arithmetic
Your factor is below 2^67, so you got the right credit. Your program found the factor in the 66-67 step, and not in the 67-68 step. The second step was never done.

Code:
gp > 2^67
%2 = 147573952589676412928
gp > f
%3 = 125181632355633596023
gp >
Assuming you will find a factor which is actually between 2^67 and 2^68 (which you did not):

You should get the credit (0.12xx) for "no factor" to 67, if you reported that bitlevel before reporting the factor. If you only reported the factor, than you only get the credit for the factor, as PrimeNet doesn't know that you did the 66-67 bitlevel too, or any other bitlevels you did. After the factor is reported, the 66-67 (or any other) bitlevel is not needed, once a factor is found, the exponent is "dead" for the project, as the associated mersenne number can't be prime. And you get no credit if you reported the bitlevel after reporting the factor. If you report the "no factor to 67" first, you get credit (0.12xx) then you report the factor (which is between 2^67 and 2^68) and you get credit for the factor. That is the right procedure.

That is the main reason why, when you report a long result file, with many factor/nofactor lines, PrimeNet checks first the "no factor" lines, to give you the right credit for "no factors" for the lower bitlevels. Then it gives you the credit for the "factors" lines. If you mess with it, like reporting the factors first, or whatever, is your problem. What you do to yourself with your own hand... (ask Chris, he knows the name ).

So you actually only did about ~85% of the FIRST bitlevel to find this factor. You got ~85% of the 0.12xx credit. Which is right.

Last fiddled with by LaurV on 2014-04-11 at 04:59 Reason: link to the factor, few typos

2014-04-11, 09:49   #5
snme2pm1

"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts

Quote:
 Originally Posted by LaurV Your program found the factor in the 66-67 step, and not in the 67-68 step.
Well I got myself quite muddled late last night!
Thanks for setting me straight as to the magnitude of the factor found.
The failed transmission of initial 118300027 TF results contributed to my confusion as to progress of matters.

I'm mostly familiar with mfaktc and mfakto and upon revisiting prime95, unsure of some of it's particular behaviours. Indeed I've used it only once a year ago for TF work as my first ever automatic assignment.
My question remains as to whether Prime95 is intended to be tolerant enough to properly communicate results by itself after commencing an assignment with the upper level altered as I did, or will matters be confounded by such meddling?
I checked to see that mfaktx notes do suggest doing same, but upon looking I did not find the same kind of invitation in prime95 notes.
I'm set to see if another similar job completes and reports by itself, but that will take some hours.

2014-04-12, 03:53   #7
snme2pm1

"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts

Quote:
 Originally Posted by LaurV Oh! You are doing TF on CPU
I made clear my interest to utilize an ancient machine (now disclosed as Athlon XP 2400+ Win XP) for some space heating labour as winter approaches. Pollard (P-1) stage 2 work would suck away all memory leaving me somewhat crippled, and incur long delays during initialisation. That donk is my most used home desktop and continues to work admirably for that purpose even after more than ten years (I replaced a couple of mainboard electrolytic capacitors), but certainly not my main instrument deployed for prime chasing and not often used for day work.
I'm holding out for a Skylake upgrade next year.

After another test, I have found another surprise.
Communication of results with Primenet did not suffer any grief this time.
Another TF exercise with altered upper level completed the first bit level and lodged such completion with PrimeNet, which I didn't expect, due to experience of need for care when using mfakto results to not report prior to the conclusion of dealing with a particular exponent.

Prime95 reported a result but the assignment was not closed.
Subsequently I have been led to looking at
http://v5.mersenne.org/v5design/v5webAPI_0.97.html
5.7 ar - Assignment Result
5.7.1 DESCRIPTION
Report a work assignment result and optionally close the assignment on the server.
5.7.2 COMMON PARAMETER DATA
5.7.2.1 Request Parameters
... in particular
d - DONE flag (integer; 0 = do not close assignment, 0 <> close assignment)

Lovely news to me; It is possible to report a result and keep the assignment open, something I had not noticed before.

Quote:
 Originally Posted by LaurV TF work...even without assignment
My attempts in this regard failed may days ago. Prime95 did not appear interested to pursue a TF exercise without a decent looking AID.

 Similar Threads Thread Thread Starter Forum Replies Last Post rekcahx Factoring 6 2011-08-19 12:45 ixfd64 Software 1 2011-02-25 00:04 Bill Bouris Conjectures 'R Us 4 2009-04-07 13:25 Zeta-Flux Factoring 2 2008-03-03 18:34 abstractius Software 4 2007-12-18 02:31

All times are UTC. The time now is 02:30.

Fri Oct 30 02:30:34 UTC 2020 up 49 days, 23:41, 1 user, load averages: 1.96, 2.37, 2.32