OFFICIAL "SERVER PROBLEMS" THREAD

[retina]

Originally Posted by GP2

There is no contradiction here. All exponents below 78 million have been tested at least once.

The entire 77M range is fully first-time tested if every exponent has either been factored, or had at least one non-Suspect LL test done, or had at least one PRP test done. That is already the case, and the range is done.

I counted 35813 exponents that have at least one factor, 18953 exponents that have had at least one non-Suspect LL test done and no PRP tests (including the one Mersenne prime), 156 exponents that have had at least one PRP test done and no LL tests, and 85 exponents that have had both at least one non-Suspect LL test and at least one PRP test.

Finally, there are two exponents 77732573 and 77879497 that have each had one PRP test and one Suspect LL test. Those are the "2" in the LLERR column, but that's just a display anomaly. They have already been cleared by virtue of the PRP test.

The simplest way of resolving the display anomaly is to do early double-checks of those two PRP results, which I have now started. This should shift that "2" into the confirmed composite column.

This sort of thing shouldn't be an issue because going forward there won't be too many more cases of the same exponent having both PRP and LL tests done on it. That was caused by confusion in manual assignments in the early days of gpuOwL implementing PRP testing.


Similarly, the outstanding NO-LL is most likely due to a hung assignment on M77231809. The system seems to think that the first-time PRP assignment is still outstanding, despite the fact that the result was already submitted. No LL test was ever done on this exponent, nor should it be at this point. Again, doing an early PRP double-check will likely resolve the problem, by shifting it into confirmed-composite status. I am poaching this exponent to do that, it's about 25% complete.




The real question, as ATH has pointed out, is why does it show 35812 factored exponents in the 77M range when in fact there are 35813? Maybe Madpoo could check the SQL that produces the https://www.mersenne.org/primenet/ report and figure out what's going on.

I think it is wrong to selectively have PRP tests appearing in some places and not others. If a pair of matching PRP tests can put the exponent into the LL-D column, then a single PRP should put an exponent into the LL column. A suspect LL should be moved out of that column if a good PRP is done later.

As it is now there is a lot of confusion about what happens with PRP tests and how they are counted in various places.

It is a little bit more than a "display anomaly", the fundamental handling of PRP tests still needs to be integrated more thoughtfully. Let's get it fixed. I suggest to remove the LL nomenclature and replace it with a clearer testing and/or tested, and similarly LL-D to be verifying/verified. This would better match the chosen wording on the milestones page also. We don't need to mention the implementation details of which test is done.

[kriesel]

Originally Posted by chalsall

My interpretation is the Captain is asleep at the wheel.

This always works out so very well....

More like the shipwright is busy with something new and wonderful. As it regularly happens.

[kriesel]

I noticed something odd the other day, and investigated, and found an anomalous server behavior goes back to March 26.

For manually assigned P-1, performed on GPUs in CUDAPm1, and manually reported results, including the proper AID in the report, the result is entered, and the assignment is also recorded as expired, apparently at the same time. I've confirmed this supposition on timing by checking an exponent's status immediately before reporting a no-factor result for it, and rechecking status afterward. See for example https://www.mersenne.org/report_expo...8000027&full=1 where it shows my P-1 result recorded, and an expiration of the P-1 assignment, occurring with the same date. Active P-1 assignments are not indicated as having _any_ expiration date when I look at my current assignments, including immediately before I report a P-1 result manually.

CPU-based Prime95 P-1 results automatically reported through Primenet seem to be fine, not getting marked expired.

I've no information on what occurs if a CPU-based P-1 computation is reported manually, since I haven't any instances of running that way.

[potonono]

On the https://www.mersenne.org/download/ page, in the "Software Source Code" section, there is an incomplete sentence that just indicates, "If you are curious anyway, you can".

That sentence used to end with sentences like ",you can download all the source code (mm.mMB). This file includes all the version vv.v source code for Windows, Linux, FreeBSD, and Mac OS X. Last updated: yyyy-mm-dd." with the "download all the source code" linked to a file.

Is that paragraph failing to generate correctly because of the link, or does it need to be removed all-together?

[GP2]

Originally Posted by GP2

Similarly, the outstanding NO-LL is most likely due to a hung assignment on M77231809. The system seems to think that the first-time PRP assignment is still outstanding, despite the fact that the result was already submitted. No LL test was ever done on this exponent, nor should it be at this point. Again, doing an early PRP double-check will likely resolve the problem, by shifting it into confirmed-composite status. I am poaching this exponent to do that, it's about 25% complete.

Hmmm. The PRP double-check of M77231809 completed about four-and-a-half hours ago, but there is still a stubborn "1" in the "Status Unproven: NO-LL" column. It did clear the "1" in the "Assigned: LL" column, though.

M77732573 and M77879497 should complete in a couple of days.

[kriesel]

Originally Posted by GP2

Hmmm. The PRP double-check of M77231809 completed about four-and-a-half hours ago, but there is still a stubborn "1" in the "Status Unproven: NO-LL" column. It did clear the "1" in the "Assigned: LL" column, though.

M77732573 and M77879497 should complete in a couple of days.

And now, my PRP assignment is marked expired on the same date as the second PRP result submission. My PRP result was submitted manually.

Perhaps not so coincidentally, all my manually submitted P-1 since March 26 have the assignment marked expired same date as each result was submitted.

[kriesel]

Originally Posted by retina

I think it is wrong to selectively have PRP tests appearing in some places and not others.
...

As it is now there is a lot of confusion about what happens with PRP tests and how they are counted in various places.

... the fundamental handling of PRP tests still needs to be integrated more thoughtfully. Let's get it fixed.

Yes to all the quoted above.

It's taking a while to get PRP integrated. More visible progress would be appreciated. Work is occurring. There are few manually submitted PRP results, and sometimes they generate issue reports, which tend to generate prompt attempts to fix the issue identified. It's slow going, since not everyone spots or reports issues, and it can be weeks between result records from someone willing to report issues with sufficient detail; resolving one issue can lead to revealing another issue the next time. Issue reports by email with screen shots and copies of the submitted result record seem to work best in my experience. (Reports on a forum thread without details seem to be at the other end of the spectrum.)

There is some utility to distinguishing between PRP and LL primality testing in the various tables. LL is only fully double checked in the sense of a matching residue confirming the calculation went correctly, by another LL check. Quality of LL check varies, because some prime95 runs will include the Jacobi check, while older executable versions will not; gpu runs made by CUDALucas or clLucas will not. A PRP run, on a recent enough version of prime95, or on gpuOwL, confirms another PRP run in the same more thorough sense if the residues match. A Gerbicz-checked PRP may confirm the composite nature of a mersenne number, but yet not confirm the LL residue or run was correct. Matching PRPs confirm each other. Matching LLs confirm each other.

I had the impression from Prime95's participation in the initial discussion of expanding GIMPS to support PRP with Gerbicz check results, that a policy of requiring primality test types to match between a first and second test to declare a mersenne number's primality settled was at least under consideration, and might have been chosen as policy, as a means of promoting the quality of the data in the GIMPS databasae.

There may not be a rule in place, that once one primality test assignment is issued for a given exponent, that others must be of the same type, either by Primenet or manual checkout. Some small subset of exponents having matching PRPs or LLs plus one or two of the other type is ok. This may occur from QA or brute-force benchmarking on software running against known-composite exponents. It's likely to occur with new primes. To frequently have primality type not match between first and second test does not seem efficient. But the resulting residues may have future utility.

Some form of representing PRP in the work distribution map table would be welcome.
Clarity, compactness, and completeness conflict.
I'd like to see twice the frequency of the header lines

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |   
  Exponent Range    | Composite  | Status Unproven  |        Assigned         |        Available        |
   Start   Count  P |   F   LL-D | LL   LLERR NO-LL |  TF    P-1   LL   LL-D  |  TF    P-1   LL   LL-D  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- 

so that one header was always on screen no matter which portion was scrolled to. Shrinking font size in the browser to get that to be the case with over 110 lines vertically, makes the characters so small they're very difficult to read.

Also, there are no columns for PRP performed or PRP DC or P-1 performed counts or TF performed counts. It's hard to tell in what ranges the various algorithms haven't even been tried yet. The table is wide now, but there's room on my screen and probably many others to widen it further.

[Madpoo]

Originally Posted by potonono

On the https://www.mersenne.org/download/ page, in the "Software Source Code" section, there is an incomplete sentence that just indicates, "If you are curious anyway, you can".

That sentence used to end with sentences like ",you can download all the source code (mm.mMB). This file includes all the version vv.v source code for Windows, Linux, FreeBSD, and Mac OS X. Last updated: yyyy-mm-dd." with the "download all the source code" linked to a file.

Is that paragraph failing to generate correctly because of the link, or does it need to be removed all-together?

Weird. The text that comes next is dynamically generated by some code... I'll take a look. Thanks for spotting it.

[Madpoo]

Originally Posted by kriesel

Also, there are no columns for PRP performed or PRP DC or P-1 performed counts or TF performed counts. It's hard to tell in what ranges the various algorithms haven't even been tried yet. The table is wide now, but there's room on my screen and probably many others to widen it further.

As noted, PRP still needs work to be integrated into reporting. The most important part that had to be done server side was simply to set it up to assign and accept PRP work because that sort of work was already happening before the server was really ready to do anything with it.

Unfortunately that also means a lot of the reporting needs to be modified and speaking for myself, schedule-wise this has been a pretty packed time which means I haven't has much time to work on the site beyond the basic maintenance. I've gone as far as creating PRP specific report pages just like LL, but when it comes to the aggregate reports that display summary progress of ranges, yeah, that all needs to be spiffed up.

I've had a task to convert that range stats to an actual HTML table anyway, but right now it's generated in a somewhat unconventional way which makes changing it more complicated. You'll all have to bear with it for now and be patient. I think the 77M-78M range is the first one to have a mix of LL and PRP first time tests in there which make it complete, but the range report isn't properly reflecting that...

Anyway, to summarize, be patient and it will be worked on as time allows.

[Madpoo]

Originally Posted by Madpoo

Weird. The text that comes next is dynamically generated by some code... I'll take a look. Thanks for spotting it.

Fixed. There was some regex to get details on the source specific ZIP file and apparently it's been broken ever since those filenames had the "b" in there for the build revisions (e.g. p95v294b7.source.zip). That "b" was throwing it off.

Good catch. It would have been broken since 29.4 build 2 I guess.

Personally I prefer version #'s like 29.4.2 or 29.4.8 if we were including sub-revisions (or just make it 29.4, 29.5, etc) Oh well. We'll manage either way.

[GP2]

Originally Posted by GP2

M77732573 and M77879497 should complete in a couple of days.

These exponents have completed and now the Work Distribution Map shows no exponents anymore under "Status Unproven: LL ERR" for the 77M line.

This was to be expected, since the previous 76M range already had a similar situation for some time. There are two exponents (76347737 and 76564567) which have a single LL test which is Suspect, but each of these also has two matching PRP tests (since February), and there are no "LL ERR" entries there either.

So now the remaining anomaly for the 77M line is: 1 exponent under "Status Unproven: NO-LL" and 35812 under "Composite: F", when it really should be none and 35813, respectively.

Maybe it's not even a PRP issue. There are no PRP assignments currently in the 77M range.

Madpoo, can you look at the SQL to see which exponent is causing the NO-LL?