mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Marin's Mersenne-aries (https://www.mersenneforum.org/forumdisplay.php?f=30)
-   -   Strategic couple and dribble checks (PRP's, P-1's, and special Certs too) (https://www.mersenneforum.org/showthread.php?t=24148)

Uncwilly 2019-03-06 21:10

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.
[B][COLOR="Red"][U]Always register your claims right away[/U][/COLOR][/B]. 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):[LIST][*]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[/LIST]
Instructions for mprime:[LIST][*]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.[/LIST]
For gpu runs, see [url]https://www.mersenneforum.org/showpost.php?p=519834&postcount=21[/url] and follow links it contains as needed.

Uncwilly 2019-03-06 21:11

Strategic LL Double Checks
 
[STRIKE]This is the location for the DC list:[/STRIKE]

[COLOR="Teal"][B]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.)[/B][/COLOR]

[CODE].[/CODE]

Uncwilly 2019-03-06 21:12

LL Triple Checks
 
This is for the list of needed triple (and higher order) checks.

[CODE][B][U][SIZE="4"]Exponents with 2 Unverified results:[/SIZE][/U][/B]
[U][B]Cat 0[/B][/U]

[U][B]Cat 1[/B][/U]

[U][B]Cat 2[/B][/U]

[U][B]Cat 3[/B][/U]

[U][B]Higher level[/B][/U]

[U][B][SIZE="4"]Exponents with 1 Suspect result + 1 Unverified result:[/SIZE][/B][/U][COLOR="DarkOrange"](use LL to clear/confirm suspect results)[/COLOR]
[U][B]Cat 1[/B][/U]

[U][B]Cat 2[/B][/U]

[U][B]Cat 3[/B][/U]

[U][B]Higher level[/B][/U]
.[/CODE]
[CODE]
[U][B][SIZE="4"]Exponents with 1 LL + 1 PRP result:[/SIZE][/B][/U] [COLOR="DarkOrange"][U](may include exponents waiting for vdf file upload)[/U][/COLOR]

[U][B]NOT gpuowl (shift 0) unless recent version with proof file generation:[/B][/U]
.[/CODE]
Quad and higher
[CODE].[/CODE]
The "Watch list". Exponents assigned to Anon or others outside this thread that have yet to show progress. Do not poach these!
[CODE]
.[/CODE]

GP2 2019-03-27 20:13

PRP double & triple checks and special Cert assignments.
 
PRP checks. [B][COLOR="Blue"]Note: please use V30 for these.[/COLOR][/B]
[code].[/code]

[B]Special Cert assignments[/B] Note: these will take much more time than a standard cert run.
[COLOR="DarkOrange"]They will show up as assigned to -Anonymous-, but will be transferred to your user id once your system reports the assignment.[/COLOR]
[code].
[/code]

Uncwilly 2019-09-05 21:15

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].[/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.

ATH 2020-01-19 11:27

[QUOTE=endless mike;535486]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.[/QUOTE]

PRP=EDDC25414116177C4F046D79BE11A463,1,2,96365519,-1,76,0,3,1

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

[B][U]1,2,96365519,-1[/U][/B]: Number to test: 1 * 2[SUP]96365519[/SUP] - 1
[B][U]76[/U][/B]: Trial factored to 2[SUP]76[/SUP]
[B][U]0[/U][/B]: 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?) [[b]EWM comment:[/b] Per the assignment-format examples on my [url=http://www.mersenneforum.org/mayer/README.html#reserve]Mlucas readme page[/url], 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.]
[B][U]3[/U][/B]: PRP base 3. This is always 3 as standard for normal GIMPS candidates.
[B][U]1[/U][/B]: 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.[/CODE]
[edit]
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 [url]https://www.mersenneforum.org/showpost.php?p=522098&postcount=22[/url]

Uncwilly 2020-07-31 16:40

[COLOR="Orange"][B]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).[/B][/COLOR]

LaurV 2022-11-05 04:42

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
[/CODE]

LaurV 2022-11-13 18:12

[QUOTE=LaurV;617184]Grrr.... [/QUOTE]

Grrrr... Double grrr....
Quintiple test for this one. I think I am onto something here.

Actually, bad news. I mean, BAD news: both residues are good. :razz:

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 0x[COLOR="Red"]0445ddd633a7abc2[/COLOR] | 20000K 0.06445 2.1185 211.85s | 5:04:12:12 36.56% |
| Nov 13 08:50:45 | M332329111 121600000 0x[COLOR="red"]f483c963ad20f670[/COLOR] | 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% |
[/CODE]

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).

Advice?

kriesel 2022-11-13 18:18

[QUOTE=LaurV;617687]Advice?[/QUOTE][STRIKE]CUDALucas[/STRIKE]; [STRIKE]CUDAPm1[/STRIKE]; [STRIKE]LL[/STRIKE] (except for confirmation of a rare PRP-P result, on ECC ram, with multiple parallel check runs); [STRIKE]100Mdigit on unreliable HW/SW combos[/STRIKE]
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/[M]332329111[/M]= 36.59%.
I could add that one to [URL]https://mersenneforum.org/showthread.php?t=26871[/URL] 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.

Uncwilly 2022-11-13 18:19

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 [I][U]might[/U][/I] queue it up on Prime95 on a machine that will take about 85 days to run it.


All times are UTC. The time now is 21:40.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.