mersenneforum.org > Data Strategic couple and dribble checks (PRP's, P-1's, and special Certs too)
 Register FAQ Search Today's Posts Mark Forums Read

 2019-03-06, 21:10 #1 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 250668 Posts Strategic couple and dribble checks (PRP's, P-1's, and special Certs too) New sticky to house the lists. Post requests for DC and TC's and claim of exponents. The mods will keep the lists maintained in the top posts. Post with requests for rechecks and exponents claimed will be removed when the lists are updated. Always register your claims right away. Those that are claimed but not registered will remain on the lists. If they are listed as being assigned to Anonymous (or others not known to be finishers) and show no progress, they will be moved to the watch list section. The lists are kept fairly up to date. The easy way to get some assignments (with Prime95):Grab the lines of the exponents that you will do. Stop Prime95. Edit your worktodo.txt, inserting the new lines, save it, and close the editor. Restart Prime95 Go to the menu Advanced-> Manual Communication Make sure "Contact PrimeNet server now" and "Send new expected completion dates to server" are checked. Hit OK After Prime95 is done communicating, look and see if any of the new exponents don't have an Assignment ID (because they were already assigned.) If they don't, stop Prime95, reopen the worktodo.txt, remove those lines, save, then restart Prime95 Instructions for mprime:Grab the lines of the exponents that you will do. Stop mprime. Edit your worktodo.txt, inserting the new lines, save it, and close the editor. Delete the line starting with LastEndDatesSent= in local.txt. Run mprime -c for force communication, and watch for errors: exponents that didn't get assignments should be removed from worktodo.txt. Restart mprime. For gpu runs, see https://www.mersenneforum.org/showpo...4&postcount=21 and follow links it contains as needed. Last fiddled with by Uncwilly on 2020-09-16 at 21:52 Reason: tweaked wording.
 2019-03-06, 21:11 #2 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 2·3·1,801 Posts Strategic LL Double Checks This is the location for the DC list: Any exponent that has had a single First Time LL should no longer have an LL DC. It should get a PRP on a machine running Prime95 v30+ or GpuOWL v 6.11-318+ that produces VDF (proof files). The extra effort to run the certification from the proof files vs the need for TC tips the balance in favour of the PRP (with the better error checking code.) Code: . Last fiddled with by Uncwilly on 2021-12-15 at 17:54 Reason: Updated wording based upon Ken's input.
 2019-03-06, 21:12 #3 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 2A3616 Posts LL Triple Checks This is for the list of needed triple (and higher order) checks. Code: Exponents with 2 Unverified results: Cat 0 Cat 1 Cat 2 Cat 3 Higher level Exponents with 1 Suspect result + 1 Unverified result:(use LL to clear/confirm suspect results) Cat 1 Cat 2 Cat 3 Higher level . Code: Exponents with 1 LL + 1 PRP result: (may include exponents waiting for vdf file upload) NOT gpuowl (shift 0) unless recent version with proof file generation: . Quad and higher Code: . The "Watch list". Exponents assigned to Anon or others outside this thread that have yet to show progress. Do not poach these! Code: . Last fiddled with by Uncwilly on 2022-12-05 at 19:40 Reason: No more
 2019-03-27, 20:13 #4 GP2     Sep 2003 50338 Posts PRP double & triple checks and special Cert assignments. PRP checks. Note: please use V30 for these. Code: . Special Cert assignments Note: these will take much more time than a standard cert run. They will show up as assigned to -Anonymous-, but will be transferred to your user id once your system reports the assignment. Code: . Last fiddled with by Uncwilly on 2022-11-07 at 23:49 Reason: The Certs were sent packing.
 2019-09-05, 21:15 #5 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 2·3·1,801 Posts Potentially bad P-1 results that need to be redone Potentially bad P-1 results that need to be redone. Place holder post. There are ~50 P-1 tests that might be bad. If Madpoo provides the list it will go here: Code: . [ewmayer] @Uncwilly: Are these results suspect due to a bug in one particular client? If so, would you or Aaron please provide [do|don't]-run-under guidance together with the assignments? [uncwilly] @ewmayer: Can't find Aaron's post at the moment. The forum search does not accept P-1 as a keyword. Look at the original date on this post and check for Aaron's post 0->30 days before. Last fiddled with by Uncwilly on 2020-03-05 at 08:36
2020-01-19, 11:27   #6
ATH
Einyen

Dec 2003
Denmark

341610 Posts

Quote:
 Originally Posted by endless mike Claimed this one. Is there a post that describes what all the fields are in a worktodo entry for PRP? I always guess and hope I did it right.
PRP=EDDC25414116177C4F046D79BE11A463,1,2,96365519,-1,76,0,3,1

Added the 2 extra arguments that can be in the assignment: ",3,1"

1,2,96365519,-1: Number to test: 1 * 296365519 - 1
76: Trial factored to 276
0: Not sure about this one. (Maybe if P-1 has been done or not? or how many PRP tests has already been done on the exponent?) [EWM comment: Per the assignment-format examples on my Mlucas readme page, a 1 following the TF bit depth means this expo has had some p-1 testing done but could use a deeper round of p-1; thus a 0 presumably means no deeper p-1 is warranted.]
3: PRP base 3. This is always 3 as standard for normal GIMPS candidates.
1: PRP type 1. This can vary between 1-5, but mostly 1 or 4 for older gpuowl tests. Prime95 and newer gpuowl versions and Mlucas? default to type 1 (and Prime95 uses type 5 for PRP-CF tests on exponents with known factor(s)).

Both PRP base and PRP type has to be the same for the PRPDC test as the original PRP test.

PRP type from undoc.txt, the "(default is 5)" is only for PRP-CF tests, the type number is 1 on normal PRP tests.

Code:
PRP supports 5 types of residues for compatibility with other PRP programs.  If
a is the PRP base and N is the number being tested, then the residue types are:
1 = 64-bit residue of a^(N-1), a traditional Fermat PRP test used by most other programs
2 = 64-bit residue of a^((N-1)/2)
3 = 64-bit residue of a^(N+1), only available if b=2
4 = 64-bit residue of a^((N+1)/2), only available if b=2
5 = 64-bit residue of a^(N*known_factors-1), same as type 1 if there are no known factors
To control which residue type is generated, use this setting in prime.txt:
PRPResidueType=n		(default is 5)
The residue type can also be set for PRP tests in worktodo.txt entries making
this option somewhat obsolete.

And also for base >3, some versions of gpuowl, PRP res type 0.
Gpuowl supported PRP res type was 1 for some versions, 4 for others, 1 currently.

Worktodo formats for all common applications are described in https://www.mersenneforum.org/showpo...8&postcount=22

Last fiddled with by ewmayer on 2020-07-12 at 23:37 Reason: Added clarification re. the "more p-1 needed?" field in PRP-DC assignments

 2020-07-31, 16:40 #7 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 2·3·1,801 Posts DC's on suspect single LL's should no longer be done. Any single suspect LL should be redone with v30 as PRP-VDF. The balance between the DC and higher than usual TC rate vs running a fresh a PRP & cert lean toward the PRP path to require fewer cycles long term. The error checking is better on PRP. TC-LLs still make sense to clean up as LL (the required quad rate is low enough).
 2022-11-05, 04:42 #8 LaurV Romulan Interpreter     "name field" Jun 2011 Thailand 2·47·109 Posts Grrr.... Code: 2022-04-10 01:19:57 Tesla P100-PCIE-16GB-0 332329111 LL 174300000 52.45%; 3431 us/it; ETA 6d 06:36; 1117f44c2589ca41 2022-04-10 01:25:41 Tesla P100-PCIE-16GB-0 332329111 LL 174400000 52.48%; 3431 us/it; ETA 6d 06:31; 10cf6268d84d1b33 2022-04-10 01:31:24 Tesla P100-PCIE-16GB-0 332329111 LL 174500000 52.51%; 3431 us/it; ETA 6d 06:25; 306c53c37660b68c 2022-04-10 01:37:07 Tesla P100-PCIE-16GB-0 332329111 LL 174600000 52.54%; 3431 us/it; ETA 6d 06:19; dcc7cf749eb8b4b2 ??? for some reason I can not find this part, albeit I looked in all gpuOwl logs... so, we go blind here for a while ??? and hope that the residues will match when we reach 224.6M - we will, of course, record cudaLucas' residues 2022-04-12 13:06:17 Tesla P100-PCIE-16GB-0 332329111 LL 224600000 67.58%; 3434 us/it; ETA 4d 06:46; 62de53d3af3ffc8a 2022-04-12 13:12:00 Tesla P100-PCIE-16GB-0 332329111 LL 224700000 67.61%; 3433 us/it; ETA 4d 06:38; 45ac1d1042ead03b 2022-04-12 13:17:43 Tesla P100-PCIE-16GB-0 332329111 LL 224800000 67.64%; 3432 us/it; ETA 4d 06:31; ba7642043752353e 2022-04-12 13:23:26 Tesla P100-PCIE-16GB-0 332329111 LL 224900000 67.67%; 3432 us/it; ETA 4d 06:25; a7d3ca752ea71ad2
2022-11-13, 18:12   #9
LaurV
Romulan Interpreter

"name field"
Jun 2011
Thailand

240068 Posts

Quote:
 Originally Posted by LaurV Grrr....
Grrrr... Double grrr....
Quintiple test for this one. I think I am onto something here.

It depends on which program, and which FFT size you use (probably which shift, too? no idea how the shift affects the story, but this is one more reason to have shift). I don't know how this affects the LL tests already done in the past with cudaLucas, or if it does. Probably, gpuOwl is not affected (and especially the PRP tests).

Code:
-----------------------------------------------------------------------------------
Continuing M332329111 @ iteration 121000001 with fft length 20000K, 36.41% done
F
-- Increasing fft length.
Using threads: square 1024, splice 64.
Continuing M332329111 @ iteration 121006114 with fft length 20736K, 36.41% done
|   Date     Time    |   Test Num     Iter        Residue        |    FFT   Error     ms/It     Time  |       ETA      Done   |
|  Nov 13  08:01:50  | M332329111 121100000  0x4dc640c54da2b797  | 20736K  0.01880   2.1831  204.96s  |   5:08:05:38  36.43%  |
|  Nov 13  08:05:29  | M332329111 121200000  0xdf87f83cbc50ffef  | 20736K  0.01953   2.1829  218.29s  |   5:08:01:43  36.46%  |
|  Nov 13  08:09:07  | M332329111 121300000  0x5129a1d6c2cd5b1d  | 20736K  0.01904   2.1833  218.33s  |   5:07:58:25  36.49%  |
|  Nov 13  08:12:45  | M332329111 121400000  0x0d5da62157144adf  | 20736K  0.01807   2.1832  218.32s  |   5:07:54:52  36.53%  |
|  Nov 13  08:16:25  | M332329111 121500000  0x407b52caeab65e11  | 20736K  0.01904   2.1830  218.30s  |   5:07:51:08  36.56%  |
|  Nov 13  08:20:03  | M332329111 121600000  0x5372658f7f2c71ed  | 20736K  0.01868   2.1963  219.63s  |   5:07:55:18  36.59%  |
SIGINT caught, writing checkpoint. Estimated time spent so far: 307:13:04
Gracefully exiting...

Continuing M332329111 @ iteration 121000001 with fft length 20000K, 36.41% done
|   Date     Time    |   Test Num     Iter        Residue        |    FFT   Error     ms/It     Time  |       ETA      Done   |
|  Nov 13  08:33:05  | M332329111 121100000  0x4dc640c54da2b797  | 20000K  0.06274   2.1186  211.86s  |   5:04:26:36  36.43%  |
|  Nov 13  08:36:37  | M332329111 121200000  0xdf87f83cbc50ffef  | 20000K  0.06543   2.1181  211.81s  |   5:04:23:00  36.46%  |
|  Nov 13  08:40:08  | M332329111 121300000  0x5129a1d6c2cd5b1d  | 20000K  0.06250   2.1183  211.83s  |   5:04:19:23  36.49%  |
|  Nov 13  08:43:40  | M332329111 121400000  0x0d5da62157144adf  | 20000K  0.06445   2.1186  211.86s  |   5:04:15:48  36.53%  |
|  Nov 13  08:47:13  | M332329111 121500000  0x0445ddd633a7abc2  | 20000K  0.06445   2.1185  211.85s  |   5:04:12:12  36.56%  |
|  Nov 13  08:50:45  | M332329111 121600000  0xf483c963ad20f670  | 20000K  0.06836   2.1313  213.13s  |   5:04:08:56  36.59%  |
SIGINT caught, writing checkpoint. Estimated time spent so far: 307:12:49
Gracefully exiting...

Continuing M332329111 @ iteration 121000001 with fft length 20000K, 36.41% done
f
-- Decreasing fft length.
Using threads: square 32, splice 256.
Continuing M332329111 @ iteration 121003602 with fft length 19683K, 36.41% done
|   Date     Time    |   Test Num     Iter        Residue        |    FFT   Error     ms/It     Time  |       ETA      Done   |
|  Nov 13  08:59:51  | M332329111 121100000  0x4dc640c54da2b797  | 19683K  0.06641   2.0996  202.39s  |   5:03:11:36  36.43%  |
|  Nov 13  09:03:22  | M332329111 121200000  0xdf87f83cbc50ffef  | 19683K  0.07422   2.1004  210.04s  |   5:03:09:41  36.46%  |
|  Nov 13  09:06:52  | M332329111 121300000  0x5129a1d6c2cd5b1d  | 19683K  0.07422   2.1004  210.04s  |   5:03:06:42  36.49%  |
|  Nov 13  09:10:22  | M332329111 121400000  0x0d5da62157144adf  | 19683K  0.07031   2.1005  210.05s  |   5:03:03:30  36.53%  |
|  Nov 13  09:13:53  | M332329111 121500000  0x407b52caeab65e11  | 19683K  0.06641   2.1005  210.05s  |   5:03:00:09  36.56%  |
|  Nov 13  09:17:23  | M332329111 121600000  0x5372658f7f2c71ed  | 19683K  0.07031   2.1130  211.30s  |   5:03:04:10  36.59%  |
So, the 20M FFT is in the weeds here. Which is a pity, because it is faster, and we used it a lot for our past tests (not all cards will run the 19M, and other FFTs are either too small, or too slow).

Also, this is verified multiple times, and not only on my cards, it is verified for A100 and V100 too (yep, I paid to gugu for it!).

gpuOwl gets the branch with 407b... (which seems the correct one) - I don't have checkpoint files for gpuOwl, only (text) residues file.

I keep the cudaLucas checkpoint at 121M, with the current shift. Anybody wants the residue file to dig deeper? Should I try to insulate it more? Like make residues every 1k or more often, and see where they start differing? I can't dig into FFT part (over my paid grade!). Or we just forget about cudaLucas, now that we have better tools? (I think that we should at least check if other FFTs and other exponents which were DC with cudaLucas are affected - there are exponents for which the first LL and the DC were both done with cudaLucas, with different shifts, so there is a slim chance we actually "certified" a wrong residue, somewhere).

Last fiddled with by LaurV on 2022-11-13 at 18:30

2022-11-13, 18:18   #10
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2·3,557 Posts

Quote:
CUDALucas; CUDAPm1; LL (except for confirmation of a rare PRP-P result, on ECC ram, with multiple parallel check runs); 100Mdigit on unreliable HW/SW combos
CUDALucas is generally slower on the same hardware & parameters than Gpuowl; CUDALucas lacks the Jacobi check; CUDALucas has known issues at larger exponents; CUDALucas can't do PRP/GEC; etc.
There's little or no value to completing runs in progress that are known to have gone wrong. All those log excerpts are CUDALucas format with today's date on them and <40% complete. 121600000/332329111= 36.59%.
I could add that one to https://mersenneforum.org/showthread.php?t=26871 after LaurV quits it at some point.

Because it already has a 0-shift result, it can't be manually reserved to prevent it being assigned to someone unaware of LaurV's current ongoing efforts.
So I've registered it as a PRP DC behind another lengthy assignment in prime95. Won't stop poachers, but will help with the unsuspecting assignments.
Roundoff error indicated is quite low in all 3 log excerpts. If it's reproducible with the fft length, it's probably not a memory error.

Last fiddled with by kriesel on 2022-11-13 at 19:13

 2022-11-13, 18:19 #11 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 2×3×1,801 Posts Can you at least submit all of your "bad" results? That way if someone runs it and it matches one of those, it will be complete. I might queue it up on Prime95 on a machine that will take about 85 days to run it.

 Similar Threads Thread Thread Starter Forum Replies Last Post Madpoo Marin's Mersenne-aries 1841 2019-07-16 03:30 fivemack NFS@Home 1 2014-11-30 07:52 theshark Information & Answers 21 2014-08-30 17:36 Optics Information & Answers 8 2009-04-25 18:23 PHinker Software 3 2004-12-18 17:08

All times are UTC. The time now is 23:39.

Mon Dec 5 23:39:22 UTC 2022 up 109 days, 21:07, 0 users, load averages: 1.30, 1.19, 1.07