OFFICIAL "SERVER PROBLEMS" THREAD

[axn]

They have a huge P-1 on https://www.mersenne.org/report_expo...lo=1277&full=1

[tha]

Originally Posted by axn

They have a huge P-1 on https://www.mersenne.org/report_expo...lo=1277&full=1

For that exponent you would expect someone to use those bounds.

[S485122]

Originally Posted by S485122

The Progress report shows one test result as being in error :

----------=-----=-- | -----=-----=-----=-----=----- | ...
  Exponent Range    | Composite  | Status Unproven  | ...
   Start   Count  P |   F    DC  |LL/PRP  ERR NO-LL | ...
----------=-----=-- | -----=-----=-----=-----=----- | ...
  10000000 61938    | 41350 20588           1       | ...

I think the exponent in question is 10496897. storm5510's PRP result is marked as suspect (which is why it shows in the ERR column I suppose.) Looking at the residue I suspect that result is good.
Anyway the Mersenne number has been LL tested and verified, PRP tested and verified, it has also been factored. Even if there are bad LL or PRP results it doesn't change the status of the exponent....

Bump !

More are factored now, but the 1 in the ERR column is still there while it shouldn't :

----------=-----=-- | -----=-----=-----=-----=----- | ...
  Exponent Range    | Composite  | Status Unproven  | ...
   Start   Count  P |   F    DC  |LL/PRP  ERR NO-LL | ...
----------=-----=-- | -----=-----=-----=-----=----- | ...
  10000000 61938    | 42085 19853           1       | ...

[kriesel]

I think this is a server processing issue, not a prime95 issue.

727272727 had an assignment for LL first test by someone else in 2017, with zero progress.
Since no P-1 had been done, I tried to manually reserve it for P-1 factoring, which failed with error 40.
Today I updated a system to prime95 v30.8b14, and manually inserted into the first worker's worktodo section, on that updated system,
PFactor=1,2,727272727,-1,80,2
I figured upon PrimeNet interaction, it would get N/A inserted in the PFactor line, leave the existing LL assignment on the server as is, and all would be well. Nope.

Upon launch of the software, it synced with the server.
Its comm window shows the following:

[Main thread Apr 24 14:50] Mersenne number primality test program version 30.8
[Main thread Apr 24 14:50] Optimizing for CPU architecture: Xeon Phi, L2 cache size: 34x1 MB
[Main thread Apr 24 14:50] Starting workers.
[Comm thread Apr 24 14:50] Registering assignment: P-1 M727272727
[Comm thread Apr 24 14:50] Assignment registered as: (AID redacted)
[Comm thread Apr 24 14:50] Sending expected completion date for M727272727: Jun 12 2022
[Comm thread Apr 24 14:50] Done communicating with server.

prime.log says:

[Sun Apr 24 14:50:04 2022 - ver 30.8]
Registering assignment: P-1 M727272727
Assignment registered as: 77E9...
Sending expected completion date for M727272727: Jun 12 2022

https://www.mersenne.org/report_expo...exp_hi=&full=1
now indicates I have an LL reservation since 2017 for it, updated today, and no P-1 assignment.
It's not wrong for a 5 year old LL reservation with 0.0% progress to get expired.

But sort of reassigned to the unwary and unwilling, a giant exponent LL, was quite unexpected.

The P-1 run time estimate is too long, but that is a separate issue.

[kriesel]

Originally Posted by kriesel

sort of reassigned to the unwary and unwilling, a giant exponent LL, was quite unexpected.

The P-1 completed and a no-factor result was reported to the server. The server shows an assignment of LL for me, since 2017, now at stage S2 92.5%, while the client installation has no PRP or LL entry in worktodo for 727272727, so the LL assignment is misplaced and orphaned, while the P-1 status is inconsistent on the server.
Reporting a P-1 unassigned result ought not mess with primality test or other pending assignments.
Easily enough fixed, somewhat, by unreserving it for LL myself.

[DrobinsonPE]

I ran a P-1 on this number once but when I manually turned in the results.json.txt, it credited me twice. I am not sure how it happened. It was the last exponent of 10 that were all turned in at the same time.

https://www.mersenne.org/report_expo...3851423&full=1

[James Heinrich]

Originally Posted by DrobinsonPE

I ran a P-1 on this number once but when I manually turned in the results.json.txt, it credited me twice.

The factor you found is a composite factor. The server split the factor and recorded the two prime factors separately, but it's an artifact of the exponent history that shows your original submitted result line (with the composite factor) twice rather than the two prime factors. It's not perfect, but it's working the way it's supposed to.

[DrobinsonPE]

Originally Posted by James Heinrich

The factor you found is a composite factor. The server split the factor and recorded the two prime factors separately, but it's an artifact of the exponent history that shows your original submitted result line (with the composite factor) twice rather than the two prime factors. It's not perfect, but it's working the way it's supposed to.

Thank you, I think I knew that but forgot and did not realize it was a composite factor until after I asked the question. I will try not to ask another stupid question.

[ixfd64]

The "Recent Cleared" page is showing the following message:

Warning: Null value is eliminated by an aggregate or other SET operation.

Is this an issue?

[James Heinrich]

Originally Posted by ixfd64

Warning: Null value is eliminated by an aggregate or other SET operation.

I think it's probably related to a result submitted yesterday that George/Aaron are already investigating.

[S485122]

Wouldn't it be a good thing to have a sticky post listing the known bugs and requests of the Mersenne server and site ?
Then if each one had a comment stating its status ("will be addressed in due time", "work in progress", "feature (live with it)", "will not be addressed", ...) there would be less duplicating of complaints, reports, ...