(Preying for) World Record P-1!

[lisanderke]

Rookie question I'm afraid, but I'm having trouble to limit P-1 to stage 1 only. What is the most reliable way to limit Prime95 to only do stage 1?

[kruoli]

You will have to exclude the "how far factored" part in the worktodo line and set e.g. B2=B1.
Pminus1=N/A,1,2,29802679,-1,1750000,1750000

[lisanderke]

Thank you! I had set it to B2=B1 before, but excluded how far factored, and that didn't seem to work. Conversely, I tried B2=0 and how far factored left in, that didn't work either.

[kriesel]

Originally Posted by lisanderke

Thank you! I had set it to B2=B1 before, but excluded how far factored, and that didn't seem to work. Conversely, I tried B2=0 and how far factored left in, that didn't work either.

how far factored is legit for PFactor, and not allowed in PMinus1. Conversely bounds are legit in Pminus1, and not in PFactor. https://www.mersenneforum.org/showpo...8&postcount=22

[lisanderke]

Huh. What I wrote before makes no sense since that should have worked (what I claim to have tried first...) Can you tell I've been getting headaches from trying to get this to work?
Now I've run into another issue, but I believe this is a bug... Please do correct me if this is not a bug but (somehow) expected behavior in 30.8, my workers are stuck at 100% and keep reporting 100% done (but actually never finishing) See attached.
I don't want to stop the workers in fear of corrupting the save file....

[kruoli]

Originally Posted by kriesel

how far factored is legit for PFactor, and not allowed in PMinus1. Conversely bounds are legit in Pminus1, and not in PFactor. https://www.mersenneforum.org/showpo...8&postcount=22

The first part is not correct. Whatsnew.txt states:

ECM and P-1 can find the best B2 value for the amount of memory prime95 is allowed to use.  For ECM,
this happens when the worktodo.txt line sets B2=100*B1 which is the default assignment from the PrimeNet
server.  For P-1, the best B2 is chosen when the worktodo.txt line specifies the trial factoring depth.
For example, "Pminus1=1,2,20000003,-1,500000,0,70" chooses the best B2 bound for B1=500000 given that
M20000003 has been trial factored to 2^70.

[James Heinrich]

Originally Posted by Prime95

@James: Can the P-1 probability calculator be changed to allow more than 95 bits of TF? Or even better, estimate the proper TF value given the amount of ECM that's been done?

I don't normally monitor new threads so I didn't see this till it was pointed out to me.
I have changed the max TF to 99 for now, if you want it bigger let me know.
I haven't got a clue how to estimate TF based on ECM?

[kruoli]

Originally Posted by James Heinrich

I haven't got a clue how to estimate TF based on ECM?

Take the estimated T-Level that is already on your site, then calculate \((\text{T-level})/\log_{10}{2}\). This is your value.
Example: M1277 has an estimated T-Level of 62.878. The analog TF bit level would be 208 or 209 (yes, very high!).

[kriesel]

Originally Posted by kruoli

The first part is not correct. Whatsnew.txt states ...

Thanks, I missed that change at v30.4/30.5, will extend the reference info to reflect it.


(edit: done)

[Prime95]

Originally Posted by lisanderke

Now I've run into another issue, but I believe this is a bug... .

Looks like a bug to me. Hopefully just a harmless reporting issue. Did the runs complete OK?

[lisanderke]

Originally Posted by Prime95

Looks like a bug to me. Hopefully just a harmless reporting issue. Did the runs complete OK?

They did not? They did?
At some point (after way too much time spent on the exponent, half an hour more than I expected them to take) some runs were "completed" and B1=x reported to Primenet. Then, I stopped the remaining exponents (while at 100% for many iterations) and restarted Prime95. That prompted IMMEDIATE reporting of B1=x complete to Primenet (Keep in mind, these runs were not "completed" in the same manner as the previous ones. These ones were "forced" to upload because Prime95 probably recognized they were at 100%?)

Two different kind of runs were uploaded to Primenet:
1. These assignments were reporting a "correct" climb up to 100%. These were then stuck at reporting 100% while seemingly reporting progress (apart from the 100% done) correctly. (in the sense that every x amount of iterations still took around 5 seconds.) Eventually they completed and reported to Primenet

2. These assignments were stopped in the "middle" of reporting 100%. Prime95 restarted, prompting immediate reporting of "results"


Now what amazes me the most is that for some reason, assignments of the second kind got MORE credit given. (the assignments that intuitively should not have "completed" whatever they were doing; also considering there was not as much time spent on these exponents)



I fear my explanation hardly makes any sense, unfortunately I did not save screenshots of the behavior I've just described. What I do have is the "results" reported to Primenet. Maybe someone else can make sense of this. 5741 and 5717 were both reported after 'completing' a run that had the 100% reporting bug. The rest (with more credit given) were restarted in the middle of this run, after the bug had taken effect (for some time)


Attached the save files (appended .txt to allow me to upload them.). Below results.txt entries. (for reference of how long these runs took, much longer than I expected them to run)

[Thu Dec 16 16:18:45 2021]
UID: x/30.8b5, M5717 completed P-1, B1=200000000, Wi4: 1794843D
UID: x/30.8b5, M5741 completed P-1, B1=200000000, Wi4: 17FA8444
[Thu Dec 16 16:22:49 2021]
UID: x/30.8b5, M5903 completed P-1, B1=200000000, Wi4: 1794843E
UID: x/30.8b5, M5861 completed P-1, B1=200000000, Wi4: 17908447
UID: x/30.8b5, M5879 completed P-1, B1=200000000, Wi4: 17FD8448
UID: x/30.8b5, M5851 completed P-1, B1=200000000, Wi4: 17EA843C



The headaches keep getting worse and worse. This all happened on 30.8b5 FYI.