OFFICIAL "SERVER PROBLEMS" THREAD

[chalsall]

Originally Posted by retina

That now leaves us with the 2 missing tests, out of 5 total, that are listed as "Status Unproven".

And the world ends, as we know it...

[GP2]

Originally Posted by GP2

The "Status Unproven" columns merely refer to exponents that haven't been verified with matching residues, which may or may not be currently assigned. The two LLERR could perhaps be "Suspect" first-time results which haven't yet been assigned for another LL test.

And in fact that seems to be the case:

77732573        LL      Suspect;2017-09-13;Jamous;4DA09FAE8A06C8__;61108850
77879497        LL      Suspect;2018-02-12;arnaud;CD50EEEB710BBA__;58080809

The above listing doesn't show it, but 77732573 has error code 00010100 and 77879497 has error code 01000200.

Also, both of these have a single PRP result and a single LL result, and no current assignments.

When PRP testing was first introduced, it wasn't co-ordinated well with LL testing. So some exponents had both kinds of tests done, one of which will end up being redundant.

So I think the mystery is cleared up.

If anyone wants to double-check the PRP results:

PRP=1,2,77732573,-1,75,0,3,1
PRP=1,2,77879497,-1,75,0,3,1

[ATH]

Originally Posted by retina

That now leaves us with the 2 missing tests, out of 5 total, that are listed as "Status Unproven".

The 2 LLERR is accounted for and 2 of the 3 in NO-LL is in the Assignment list. But still the last of the 3 NO-LL is unaccounted for, which in my script count is in the Factored column.

[GP2]

Originally Posted by ATH

The 2 LLERR is accounted for and 2 of the 3 in NO-LL is in the Assignment list. But still the last of the 3 NO-LL is unaccounted for, which in my script count is in the Factored column.

Hmm, yes, I count 35813 Factored at the moment (which includes 77191483 and 77197033 which previously had one LL test done), but the statistics page currently shows 35812. It's not an updating problem, since it's updated hourly and it's been at that level for more than a few hours.

So there's a problem with the statistics report, and it doesn't seem to be related to PRPs at all.

[GP2]

Originally Posted by chalsall

And the world ends, as we know it...

A strange statement.

Much of science and of programming consists of sniffing out anomalies and investigating them.

[GP2]

Originally Posted by retina

I don't see that extra assignment for 77231809. This link only shows two assignments. 77959619 and 77998639.

In your output why is the ordering not correct? 77231809 appears out of order. Did the server output it in that order?

If you click on the link to 77231809, the assignment shows up there. The original tester has a self-double-check assigned, or possibly this reflects a hung original assignment.

There is something weird though, because 6.0% done as of 2018-04-09 has turned into 0.0% done as of 2018-04-12.

I am now poaching that PRP double check and we'll see if anything changes when it completes in a few weeks.

In my original output I sorted by work type, which is why the assignments appeared out of order.

[petrw1]

GIMPS Milestones Report

Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert the value NULL into column 'm_value', table 'primenet.dbo.t_gimps_milestones'; column does not allow nulls. UPDATE fails., SQL state 23000 in SQLExecDirect in C:\inetpub\www\report_milestones\default.php on line 38 Warning: odbc_fetch_array() expects parameter 1 to be resource, boolean given in C:\inetpub\www\report_milestones\default.php on line 39 Warning: odbc_free_result() expects parameter 1 to be resource, boolean given in C:\inetpub\www\report_milestones\default.php on line 42

Progress toward next GIMPS milestones (last updated UTC, updates every 15 minutes)

====================================

A minute later no error

[Madpoo]

Originally Posted by petrw1

GIMPS Milestones Report

Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert the value NULL into column 'm_value', table 'primenet.dbo.t_gimps_milestones'; column does not allow nulls. UPDATE fails., SQL state 23000 in SQLExecDirect in C:\inetpub\www\report_milestones\default.php on line 38 Warning: odbc_fetch_array() expects parameter 1 to be resource, boolean given in C:\inetpub\www\report_milestones\default.php on line 39 Warning: odbc_free_result() expects parameter 1 to be resource, boolean given in C:\inetpub\www\report_milestones\default.php on line 42

Progress toward next GIMPS milestones (last updated UTC, updates every 15 minutes)

====================================

A minute later no error

On the one hand we shouldn't be displaying the raw PHP errors to everyone, but on the other hand it's useful for troubleshooting. LOL

In this case it sounds like the routine that updates those milestones every 15 minutes hung up on something or another... probably not really NULL data but something else along the way. I'm glad it self-corrected. "m_value" is the # of exponents left to test... it should never be null ordinarily... zero maybe, but not NULL.

[retina]

Now the reports seem to be conflicting about what is happening.

Originally Posted by https://www.mersenne.org/report_milestones/

April 18, 2018 All exponents below 78 million tested at least once.

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  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  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  77000000 55009  1 | 35812   607 18586     2     1 |                 1    35 |                   18552 |

So which is it? Both can't be right.

[S485122]

As stated earlier by me, there is something weird on the Active Assignments page. The problem only seem to exist in the double-check range. (In the "first-time" range I did not see this kind of behaviour.)

When one checks the "Exclude double-check assignments" tick box, the current active TF assignments are not shown.

For instance at this moment :

Excluding no category all 936 active assignments are shown.
https://www.mersenne.org/assignments...xp_hi=45000000

Excluding trial factoring assignments 847 assignments are shown.
https://www.mersenne.org/assignments...5000000&extf=1

Excluding double-check assignments 0 assignments are returned, there should be 89 trial factoring assignments.
https://www.mersenne.org/assignments...00000&exdchk=1

Jacob

[GP2]

Originally Posted by retina

Now the reports seem to be conflicting about what is happening.

----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  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  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
  77000000 55009  1 | 35812   607 18586     2     1 |                 1    35 |                   18552 |

So which is it? Both can't be right.

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.