Register FAQ Search Today's Posts Mark Forums Read

2021-05-23, 22:33   #2157
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

3×52×79 Posts

Quote:
 Originally Posted by Prime95 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.
Thanks for checking. Your reply implies up to ~595.8M should be ok, if it has the same limits as prime95 ffts. If the workaround involves the server putting the jumbos aside for batch processing by another system (AWS? Inexpensive desktop or laptop?), I suggest the workaround support the full 1G mersenne.org space, which implies AVX512 processor, not FMA3 at 920.8M cap. (You build em, we break em. Better to find issues well ahead of the pack, than when the wavefront reaches the boundary. There are more jumbos running.)

2021-05-23, 23:27   #2158
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

1E0816 Posts

Quote:
 Originally Posted by kriesel Thanks for checking. Your reply implies up to ~595.8M should be ok,
I'll download the proof to my AVX-512 laptop, modify the server processing program to spit out SQL statements rather than call SQLServer. Then I'll upload the smaller result file and execute the SQL statement.

A pain, but fairly rare event.

2021-05-24, 17:03   #2159
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

3·52·79 Posts

Quote:
 Originally Posted by Prime95 A pain, but fairly rare event.
Thank you.

Something else I note about server behavior:
It will manually issue PRP DC assignments, and then very quickly treat them as cat 0 PRP first test assignments, not PRP DC (PRP-D), and expiring in 7 days from issue.

Part of my pending assignments list:
Code:
CPU Name        Core   Exponent     Type  Cat originally  assigned      updated       expires (days)
Manual testing    1    84607561      PRP    0    0        2021-05-18    2021-05-18            1
Manual testing    1    84944921      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    84969113      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    85141577      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    85427897      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    86042767      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    86961583      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    87051017      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    87215537      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    88102523      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    88391669      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    89023807      PRP    0    0        2021-05-23    2021-05-23            6
Manual testing    1    89877037      PRP    0    0        2021-05-23    2021-05-23            6
The issued assignments begin "PRP=". That is, unlike LL, which has forms Test= and Doublecheck=, there's nothing to distinguish a first PRP from a second. But the server could keep track of whether a first or second was requested, and then apply the appropriate first test or doublecheck assignment rules' differing exponent thresholds versus exponent. For LL DC, the above exponents would be Cat 4, with a year to complete. Because they are PRP not LL, these DC or TC assignments are being treated like Cat 0 LL first tests instead. These are mostly actually from the strategic triple checking list with a first LL and a first PRP already recorded for each before the PRP DC assignments were issued.
Handling PRP DC expiration properly becomes more important as more migration away from LL to PRP occurs, including PRP/GEC/proof as DC for LL first tested exponents. Slow systems needing to run smaller exponents to avoid expiration issues with wavefront first tests will run afoul of the exceptionally rapid expiration of PRPDC assignments, causing waste of computation time, as things now stand.

This issue has affected both manual and automatic assignments and has been reported multiple times, multiple threads, spanning more than two years. Some previous references:
https://mersenneforum.org/showpost.p...postcount=1789 (March 2020)
https://mersenneforum.org/showpost.p...04&postcount=1 (March 2020)
https://mersenneforum.org/showpost.p...67&postcount=2 (March 2020)
https://www.mersenneforum.org/showpo...&postcount=445 (January 2020)
https://www.mersenneforum.org/showpo...&postcount=453 (January 2020)
https://mersenneforum.org/showpost.p...18&postcount=4 (April 2019)
https://mersenneforum.org/showpost.p...24&postcount=5 (April 2019, manual extend doesn't)
https://mersenneforum.org/showpost.p...postcount=1675 (March 2019)

Last fiddled with by kriesel on 2021-05-24 at 17:46

2021-05-24, 20:06   #2160
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

23·312 Posts

Quote:
 Originally Posted by Prime95 I'll download the proof to my AVX-512 laptop, modify the server processing program to spit out SQL statements rather than call SQLServer. Then I'll upload the smaller result file and execute the SQL statement. A pain, but fairly rare event.
It wasn't too difficult. I quickly had one of my computers quickly grab the CERT assignment. Two days for the certification. Ugh, but far better than 500 days for a full DC!

2021-05-24, 20:19   #2161
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

23×312 Posts

Quote:
 Originally Posted by kriesel Thank you. Something else I note about server behavior: It will manually issue PRP DC assignments, and then very quickly treat them as cat 0 PRP first test assignments, not PRP DC (PRP-D), and expiring in 7 days from issue.
Frankly, I'm scared to touch that server code.

Question: Do the assignments actually expire in 7 days or are they just reported as cat 0's expiring in 7 days?

Much of the mess comes from retrofitting PRP into a server designed for an LL world. The server does not issue "PRPDC=exponent,..." from the web pages because old versions of prime95 and perhaps even current versions of gpuowl, msieve do not understand that worktodo.txt syntax.

New versions of prime95 do understand that syntax and only generate that syntax when the assignment is obtained using the PrimeNet API. Prime95 only uses the "DC" info for computing chance of finding a new Mersenne prime in the Test/Status dialog box.

The SQL tables on the server use work type 150 for both PRP and PRPDC. These should be split into two different work types but I'm positive that doing so will have ramifications in both the web pages and PHP results processing. Worth doing, but not a quick fix.

 2021-05-24, 20:56 #2162 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 100111100010012 Posts The PRP-CF and PRP-CF-DC's also show up with a short time to expire until they report in again.
2021-05-24, 21:42   #2163
chalsall
If I May

"Chris Halsall"
Sep 2002

26·157 Posts

Quote:
 Originally Posted by Prime95 Frankly, I'm scared to touch that server code.
If I may please share... Yeah. I resonate with that.

It's currently working. And there are change requests which are reasonable. But most don't have a clue how complex the back-end is. And humans heuristically make mistakes.

IMO, the World will be much easier when Humans aren't involved...

Fortunately, it won't be for too much longer. GAI is coming "really soon now"...

Seriously.

2021-05-24, 23:16   #2164
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

3×52×79 Posts

Quote:
 Originally Posted by Prime95 Frankly, I'm scared to touch that server code. Question: Do the assignments actually expire in 7 days or are they just reported as cat 0's expiring in 7 days?
I believe the behavior depends on where the exponent stands relative to first test thresholds. I've had jumbo exponent manual assignments expire yet linger in my assignment list for months afterward. And on rare occasions, requested that someone else's years-expired assignment get revoked so I could take one over. I could hold back a result tomorrow for 84607561 for a bit to force a test of expiration behavior. May annoy whoever gets assigned it if it does expire, though. I do recall another user reporting in some PRPDC for an exponent that I was still running in prime95/PrimeNet connected, but that may not have been due to expiration.
Quote:
 Much of the mess comes from retrofitting PRP into a server designed for an LL world. The server does not issue "PRPDC=exponent,..." from the web pages because old versions of prime95 and perhaps even current versions of gpuowl, msieve do not understand that worktodo.txt syntax. New versions of prime95 do understand that syntax and only generate that syntax when the assignment is obtained using the PrimeNet API. Prime95 only uses the "DC" info for computing chance of finding a new Mersenne prime in the Test/Status dialog box. The SQL tables on the server use work type 150 for both PRP and PRPDC. These should be split into two different work types but I'm positive that doing so will have ramifications in both the web pages and PHP results processing. Worth doing, but not a quick fix.
I'm a complete SQL illiterate, and stumble through PHP as a reader, so no help forthcoming from this corner. But I imagined something like another field, that is blank for already-issued assignments, and records issued as first test or DC from some point forward. That could buy time until client programs support PRPDC syntax, or reduce the motive for such a worktodo format change. I note I don't even have the PRPDC form in the worktodo formats reference post yet; fixing that now.

Quote:
 Originally Posted by Uncwilly The PRP-CF and PRP-CF-DC's also show up with a short time to expire until they report in again.
Manual assignments on GPUs have no way to report progress before a completed result is submitted. I requested some provision for that years ago. Other things have kept those who could attempt it busy, including transition to PRP/GEC, the whole proof development, and continually keeping a lot of the plates spinning.

Quote:
 Originally Posted by Prime95 It wasn't too difficult. I quickly had one of my computers quickly grab the CERT assignment. Two days for the certification. Ugh, but far better than 500 days for a full DC!
Will recheck -proof level on any application instances that may start work on jumbos. Could save a day or two each for any future starts' verifications. There are several jumbo PRP first tests already "in-flight" as manual assignments. Thanks for the verification run. If it becomes too much, as more jumbos' proof files come in, you could consider passing back the reduced-size-result file(s) perhaps on an emailed dropbox location for me to run verification on with a little guidance.

 2021-05-25, 00:55 #2165 slandrum   Jan 2021 California FD16 Posts Cat 0 DC is shrinking Also related to the server updates for PRP not taking everything into account, the 200 assignment count for Cat 0 DC is setting the threshold based on exponents that have had one or more unverified LL done on them and no verified LL. It's not taking into account exponents that have been cleared by PRP, and the number of cases where that has occurred is going up. Some of the DC triple checks are now done with PRP, and I see at least one account that seems to be just changing all of their DC assignments from LL to PRP. The end result is that there are now far fewer than 200 actual cat 0 DC assignments. At some point there won't be any and the cat 0 threshold will stop moving at all and will be below the cleared DC level if this doesn't get corrected. I imagine this is also having an effect on the other DC categories, but it's less noticeable than how it's affecting cat 0.
2021-05-25, 01:42   #2166
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

172516 Posts

Quote:
 Originally Posted by slandrum Some of the DC triple checks are now done with PRP, and I see at least one account that seems to be just changing all of their DC assignments from LL to PRP.
It's not necessary for the user to change them, from LL DC to PRP, if obtaining manual assignments. The server will issue them as PRP, for the benefit of much higher DC/TC reliability and slightly higher efficiency, with PRP/GEC/proof-gen/cert, than for additional LL with or without Jacobi and a 1-2% error rate in the final LL residue.
Attached Thumbnails

Last fiddled with by kriesel on 2021-05-25 at 01:43

 2021-05-27, 14:43 #2167 axn     Jun 2003 121148 Posts P-1 composite factor processing issue Code: Splitting composite factor 1180771434560658837993097742708585564114271908632033 into: * 5057930432559607209809 * 233449520570633819891043649937 processing: P-1 factor 5057930432559607209809 for M3731081 (B1=14,000,000, B2=700,000,000) (72.099 bits) CPU credit is 7.8239 GHz-days. processing: P-1 factor 233449520570633819891043649937 for M3731081 (B1=14,000,000, B2=700,000,000) (97.559 bits) Error code: 40, error text: You have already sent in this P-1 result for M3731081 Second factor is not properly recorded: https://www.mersenne.org/report_expo...3731081&full=1

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Lounge 39 2015-05-19 01:08 ewmayer Science & Technology 41 2014-04-16 11:54 cheesehead Soap Box 56 2013-06-29 01:42 cheesehead Soap Box 61 2013-06-11 04:30 Dubslow Programming 19 2012-05-31 17:49

All times are UTC. The time now is 16:31.

Sun Dec 5 16:31:32 UTC 2021 up 135 days, 11 hrs, 1 user, load averages: 1.50, 2.04, 2.20