OFFICIAL "SERVER PROBLEMS" THREAD - Page 196

Flaukrotist · 2021-05-10, 20:24

Quote:

Originally Posted by Uncwilly

New format of report here: https://www.mersenne.org/report_ll/ breaks the exponents up into chunks. This broke my import function I used to keep the strategic DC/TC list up to date. Are the spaces really useful?

On this page, I currently see unverified residues unmasked and the page crashes for some queries for a specific user which I suspect has not a single LL test done.

James Heinrich · 2021-05-10, 20:28

Quote:

Originally Posted by Flaukrotist

On this page, I currently see unverified residues unmasked and the page crashes for some queries for a specific user which I suspect has not a single LL test done.

Can you please PM me some specific examples of both of these problems?

Uncwilly · 2021-05-10, 21:11

Quote:

Originally Posted by James Heinrich

Are you not using the Simple Text Report format? If you're parsing something automatically that's the format you should be parsing, the HTML output might change at any time, the text output should be consistent. And you can get more results (50k instead of 10k).

I am using Excel's power queries. It parses the HTML table fine into cells.

What I am looking for is recent LL results (less than 6 months old) in a range from the trailing edge of the DC to ~35,000,000 above that, that are not currently assigned, and don't have a matching DC. This catches all of the new bad DC's in that range. Screening out those that are assigned takes 50 pokes at the db.

I query the milestones page, the assignment rules page, and the LL results. Then, I request the LL assignments from the DC bottom to that plus 35,000,000. When those results come in, I take the last on the list as the first parameter for the next search. Lather rinse repeat.

I can rework my queries to fetch that page, then parse out the exponent in a second column, then on you go.

James Heinrich · 2021-05-10, 21:21

Quote:

Originally Posted by Flaukrotist

On this page, I currently see unverified residues unmasked and the page crashes for some queries for a specific user which I suspect has not a single LL test done.

The unmasked residues problem is fixed (that was my fault, sorry

).

I can look at the problem with crashing with specific user if you PM me more details.
edit: URL redirection crash found and fixed, thanks.

Happy5214 · 2021-05-13, 05:20

The server is no longer displaying the bounds and sigma for found ECM factors, at least with mprime 30.6. mersenne.ca doesn't seem able to pull that info as a result. Is this intentional?

FWIW, my factor on 1970599 was found on curve 6 with B1=50000, B2=6750000, and sigma=7616114112910180, in case James wants to add that info for me. I'm not sure what the server kept from my JSON submission.

James Heinrich · 2021-05-13, 13:42

Quote:

Originally Posted by Happy5214

The server is no longer displaying the bounds and sigma for found ECM factors

This is not intentional, it is an oversight in the parsing code. I have sent details for Aaron to fix, once he does it should display correctly (and if he fixes it before 00h UTC it will automatically include said details in the export to mersenne.ca)

James Heinrich · 2021-05-15, 14:01

Quote:

Originally Posted by Happy5214

The server is no longer displaying the bounds and sigma for found ECM factors, at least with mprime 30.6. mersenne.ca doesn't seem able to pull that info as a result.

The F-ECM results should now correctly display bounds and sigma, and this information will be exported to mersenne.ca
We have also retroactively updated 3288 past results with the missing information.

Happy5214 · 2021-05-17, 02:45

Quote:

Originally Posted by James Heinrich

The F-ECM results should now correctly display bounds and sigma, and this information will be exported to mersenne.ca
We have also retroactively updated 3288 past results with the missing information.

Thanks for the quick fix!

kriesel · 2021-05-23, 18:22

On a reliable Radeon VII GPU, in Gpuowl V6.11-364, I ran to completion a PRP with proof power 8 a manual assignment of M642589933. The gpuowl log shows generation of a proof level 8 and result by 2021-05-17 20:19 local time (US CDT, UTC-0500).

The composite PRP result was manually reported 5/17/21, probably late evening.
The proof file was dragged and dropped to the host system's prime95 working directory for automatic upload.

The system's prime95 results.txt contains a log entry showing the proof file was uploaded.
[Mon May 17 22:18:14 2021]
Proof file 642589933-8.proof successfully uploaded

https://www.mersenne.org/report_expo...exp_hi=&full=1 indicates an unverified (reliable) PRP result dated 2021-05-18 (probably UTC clock), and does not list either a verification result or a verification assignment.

https://www.mersenne.ca/exponent/642589933 indicates one masked PRP residue, no verification, and status double-checked. Those seem contradictory.
It shows the effort for the full PRP as 19,433.883 GHD, so I estimate the proof verification as ~1/256 that, ~76 GHD, about 64% the work of a 56M LLDC. That's rather substantial compared to the usual verification effort. My last 100 certs ranged from 0.0021 to 1.9 GHD. (Sorry, didn't think to go power 9 in time for the M642M run.) This verification could take days, depending on where it lands. But normally a verification assignment is part of the mersenne.org exponent report, for the duration.

Checking high exponent PRP results with https://www.mersenne.org/report_prp/...exfactor=1&B1=, (It would be nice if counts per unverified, verified, or bad could be added to that report.):
The highest exponent indicating PRP verified, has verification by prp proof & cert, and is less than 500M: https://www.mersenne.org/report_expo...4949303&full=1

What happened to the verification task for M642589933 on mersenne.org?
Does PRP verification work for exponents 500M to 1G?
How long may verification of large exponents take when things are working correctly?
Why the internal inconsistency on mersenne.ca?

Prime95 · 2021-05-23, 19:38

Processing the proof file failed on the server. The server does not have the Intel instruction set necessary to process an exponent this large.

I need to think of a workaround.

James Heinrich · 2021-05-23, 22:05

Quote:

Originally Posted by kriesel

Why the internal inconsistency on mersenne.ca?

That data is just not available. I have removed the "status" field for PRP from the table at the top of exponent pages on mersenne.ca

2021-05-13, 05:20	#2150
Happy5214 "Alexander" Nov 2008 The Alamo City 2⁴×43 Posts	The server is no longer displaying the bounds and sigma for found ECM factors, at least with mprime 30.6. mersenne.ca doesn't seem able to pull that info as a result. Is this intentional? FWIW, my factor on 1970599 was found on curve 6 with B1=50000, B2=6750000, and sigma=7616114112910180, in case James wants to add that info for me. I'm not sure what the server kept from my JSON submission. Last fiddled with by Happy5214 on 2021-05-13 at 05:25 Reason: Info

2021-05-23, 18:22	#2154
kriesel "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 31×173 Posts	M642M server side oddities On a reliable Radeon VII GPU, in Gpuowl V6.11-364, I ran to completion a PRP with proof power 8 a manual assignment of M642589933. The gpuowl log shows generation of a proof level 8 and result by 2021-05-17 20:19 local time (US CDT, UTC-0500). The composite PRP result was manually reported 5/17/21, probably late evening. The proof file was dragged and dropped to the host system's prime95 working directory for automatic upload. The system's prime95 results.txt contains a log entry showing the proof file was uploaded. [Mon May 17 22:18:14 2021] Proof file 642589933-8.proof successfully uploaded https://www.mersenne.org/report_expo...exp_hi=&full=1 indicates an unverified (reliable) PRP result dated 2021-05-18 (probably UTC clock), and does not list either a verification result or a verification assignment. https://www.mersenne.ca/exponent/642589933 indicates one masked PRP residue, no verification, and status double-checked. Those seem contradictory. It shows the effort for the full PRP as 19,433.883 GHD, so I estimate the proof verification as ~1/256 that, ~76 GHD, about 64% the work of a 56M LLDC. That's rather substantial compared to the usual verification effort. My last 100 certs ranged from 0.0021 to 1.9 GHD. (Sorry, didn't think to go power 9 in time for the M642M run.) This verification could take days, depending on where it lands. But normally a verification assignment is part of the mersenne.org exponent report, for the duration. Checking high exponent PRP results with https://www.mersenne.org/report_prp/...exfactor=1&B1=, (It would be nice if counts per unverified, verified, or bad could be added to that report.): The highest exponent indicating PRP verified, has verification by prp proof & cert, and is less than 500M: https://www.mersenne.org/report_expo...4949303&full=1 What happened to the verification task for M642589933 on mersenne.org? Does PRP verification work for exponents 500M to 1G? How long may verification of large exponents take when things are working correctly? Why the internal inconsistency on mersenne.ca? Last fiddled with by kriesel on 2021-05-23 at 18:39

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Official "Faits erronés dans de belles-lettres" thread	ewmayer	Lounge	39	2015-05-19 01:08
Official "all-Greek-to-me Fiction Literature and Cinema" Thread	ewmayer	Science & Technology	41	2014-04-16 11:54
Official "Lasciate ogne speranza" whinge-thread	cheesehead	Soap Box	56	2013-06-29 01:42
Official "Ernst is a deceiving bully and George is a meanie" thread	cheesehead	Soap Box	61	2013-06-11 04:30
Official "String copy Statement Considered Harmful" thread	Dubslow	Programming	19	2012-05-31 17:49

2021-05-23, 19:38	#2155
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2×53×71 Posts	Processing the proof file failed on the server. The server does not have the Intel instruction set necessary to process an exponent this large. I need to think of a workaround.