mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet

Reply
 
Thread Tools
Old 2014-04-10, 10:46   #1
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts
Default 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?
snme2pm1 is offline   Reply With Quote
Old 2014-04-10, 23:45   #2
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts
Default

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.
snme2pm1 is offline   Reply With Quote
Old 2014-04-11, 04:10   #3
kladner
 
kladner's Avatar
 
"Kieren"
Jul 2011
In My Own Galaxy!

22·3·72·17 Posts
Default

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.
kladner is offline   Reply With Quote
Old 2014-04-11, 04:46   #4
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

22·7·317 Posts
Default

Quote:
Originally Posted by snme2pm1 View Post
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
LaurV is offline   Reply With Quote
Old 2014-04-11, 09:49   #5
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts
Default

Quote:
Originally Posted by LaurV View Post
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.
snme2pm1 is offline   Reply With Quote
Old 2014-04-11, 10:33   #6
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

22·7·317 Posts
Default

Oh! You are doing TF on CPU then? Sorry I didn't really get this. Someone said it before, but I didn't fully understand it. Well... Your time, your electricity. Doing TF on CPU nowadays, when TF on GPU is a thousand times faster, it is a complete waste of resources, unless your CPU is so old it can't do a proper DC, and your computer has so less memory it can't do a proper P-1.

To answer your question, yes, Prime95 can take care of itself, if you set the right user name (and optional computer name) in the Test/PrimeNet menu. You can also modify (manual editing) the bitlevels in the "Factor=" lines, freely, if you want to do more TF work that you assigned, or even without assignment, just be careful if you do this during P95 is working, then NEVER touch the first line of assignment, for each worker (the one which is under work by p95). If you want to do that, stop (and exit, from the test menu) p95 first. Then edit, and restart.

The assignments will be completed and sent automatically, and you will be properly credited.

Again, my humbled opinion: this is wasting of time and resources, to do TF on CPU nowadays. Disregard it, if your reason is whatever else, like didactic, etc.
LaurV is offline   Reply With Quote
Old 2014-04-12, 03:53   #7
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts
Default

Quote:
Originally Posted by LaurV View Post
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 View Post
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.
snme2pm1 is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Extended Cunningham or so rekcahx Factoring 6 2011-08-19 12:45
Prime95 26.x credit calculation ixfd64 Software 1 2011-02-25 00:04
Proth theorem extended Bill Bouris Conjectures 'R Us 4 2009-04-07 13:25
Extended Cunningham tables Zeta-Flux Factoring 2 2008-03-03 18:34
Prime95's backups broken? 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.