mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Marin's Mersenne-aries (https://www.mersenneforum.org/forumdisplay.php?f=30)
-   -   processed dc and tc posts (https://www.mersenneforum.org/showthread.php?t=24152)

kriesel 2020-03-18 22:11

[QUOTE=ewmayer;540098]LOL, I hadn't noticed that the Res64 was itself confessing its badness! :) Anyhow, once my re-run-from-30M gets close, I'll save a copy of the restartfile in case I want to re-run a small subinterval with finer-than-10K granularity.

Ken, I assume your DC run has completed or is close? Still don't see your result appearing on the exponent page.[/QUOTE]At ~92% now. I'm also throwing it through a PrimeNet-bounds P-1 factoring which is likely to finish first. I will post LL 1M-pitch interim residues here after final residues are compared and results are submitted to PrimeNet. Expect ~6pm Calif time. And I will also state whether uncwilly's fourth-test is needed.

ewmayer 2020-03-18 22:38

[QUOTE=Uncwilly;540100][code][2020-02-13 23:10:28] M50699483 Iter# = 6000000 Res64: 0C3E78B1C77FA688. shift: 33080656[/code]
[CODE][Mar 18 14:19] M50699483 interim LL residue AF0BF1AEDBD6D468 at iteration 6000000[/CODE]
I guess my shift is not zero.[/QUOTE]

Well, that's kinda silly - my Mlucas run also used nonzero shift, but I have the code remove the shift for purposes of Res64 reporting and writing-residue-to-savefile, specifically to ease such side-by-side-run cross-comparison.

But wait - whenever we have a new prime verification George or someone else does a Prime95/mprime run and cross-compares Res64s to one of the other codes. So there must be a reporting option which causes unshifted-residue Res64 vaues to get printed. (But IMO that shouldn't need a special flag to be set).

kriesel 2020-03-18 22:47

[QUOTE=Uncwilly;540100][code][2020-02-13 23:10:28] M50699483 Iter# = 6000000 Res64: 0C3E78B1C77FA688. shift: 33080656[/code][CODE][Mar 18 14:19] M50699483 interim LL residue AF0BF1AEDBD6D468 at iteration 6000000[/CODE]I guess my shift is not zero.[/QUOTE]If using prime95 or mprime, there's an option to print 3 successive residues. That's necessary because those programs start the counter at 2, not 0, ending at p, not p-2. So the usual output is two iterations early. Mlucas and others start at 0, as the Lucas-Lehmer series does; s[SUB]0[/SUB]=4, s[SUB]n+1[/SUB]=(s[SUB]n[/SUB][SUP]2[/SUP]-2) mod Mp.

Res64 values output by the programs are hexadecimal representations of the least significant 64 bits of an LL (or PRP or P-1) iteration result. Matching computation type, input, and iteration number is required, as well as dealing with shift so the LSBs can be located and converted to hex. Off-by-two on iteration count is a difference of long standing, that must be handled by the user of prime95 or mprime reading its output, as I recall. What most programs call iteration x-2, prime95 calls x. So compare prime95 iteration x+2 to Mlucas iteration x or CUDALucas iteration x.

ewmayer 2020-03-18 22:55

[QUOTE=kriesel;540108]If using prime95 or mprime, there's an option to print 3 successive residues. That's necessary because those programs start the counter at 2, not 0, ending at p, not p-2. So the usual output is two iterations early. Mlucas and others start at 0, as the Lucas-Lehmer series does; s[SUB]0[/SUB]=4, s[SUB]n+1[/SUB]=(s[SUB]n[/SUB][SUP]2[/SUP]-2) mod Mp.[/QUOTE]

Ah, I thought Uncwilly already had said option (another "should be the default" item) enabled. So this is the 2-iteration offset, not anything related to the shift, then.

Uncwilly 2020-03-18 23:29

[QUOTE=kriesel;540108]If using prime95 or mprime, there's an option to print 3 successive residues.[/QUOTE]
[QUOTE=ewmayer;540109]Ah, I thought Uncwilly already had said option (another "should be the default" item) enabled. So this is the 2-iteration offset, not anything related to the shift, then.[/QUOTE]It is doing that. I just posted the exact number. I am not near that machine for about 16 hours. I will post the others when I get there (provided that I can.)

kriesel 2020-03-19 00:36

Uncwillly's run is not needed. I have a match to Stephan Grupp's final res64.
CUDALucas V2.06 1M interval outputs below.

[CODE]| Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done |
| Mar 17 14:40:04 | M50699483 1000000 0xff270405ea0d7239 | 2688K 0.26563 2.0281 101.40s | 1:03:59:10 1.97% |
| Mar 17 15:13:53 | M50699483 2000000 0x10bd8630cdc36e73 | 2688K 0.28125 2.0286 101.43s | 1:03:26:06 3.94% |
| Mar 17 15:47:43 | M50699483 3000000 0xd4f95c0fb91ad1ee | 2688K 0.25000 2.0291 101.45s | 1:02:52:47 5.91% |
| Mar 17 16:21:34 | M50699483 4000000 0x2f3d4d841dd790ed | 2688K 0.28125 2.0296 101.48s | 1:02:19:17 7.88% |
| Mar 17 16:55:25 | M50699483 5000000 0x6762222e6dac7a3d | 2688K 0.28125 2.0299 101.49s | 1:01:45:49 9.86% |
| Mar 17 17:29:17 | M50699483 6000000 0x0c3e78b1c77fa688 | 2688K 0.26563 2.0317 101.58s | 1:01:12:17 11.83% |
| Mar 17 18:03:10 | M50699483 7000000 0x62afd692a5ec4eb2 | 2688K 0.28125 2.0326 101.63s | 1:00:38:43 13.80% |
| Mar 17 18:37:03 | M50699483 8000000 0x9f2ac42f44fa0d49 | 2688K 0.25000 2.0329 101.64s | 1:00:05:08 15.77% |
| Mar 17 19:10:57 | M50699483 9000000 0x2572440b76cf7b14 | 2688K 0.25000 2.0326 101.63s | 23:31:33 17.75% |
| Mar 17 19:44:50 | M50699483 10000000 0x5d942313da74c513 | 2688K 0.28125 2.0331 101.65s | 22:57:51 19.72% |
| Mar 17 20:18:44 | M50699483 11000000 0xaf441cb0956493cf | 2688K 0.25391 2.0338 101.69s | 22:24:08 21.69% |
| Mar 17 20:52:37 | M50699483 12000000 0xfd12342a64d97b8f | 2688K 0.25000 2.0335 101.67s | 21:50:23 23.66% |
| Mar 17 21:26:31 | M50699483 13000000 0x2e9753d14381b557 | 2688K 0.28125 2.0331 101.65s | 21:16:38 25.64% |
| Mar 17 22:00:25 | M50699483 14000000 0xde3c314364459c1b | 2688K 0.28125 2.0337 101.68s | 20:42:52 27.61% |
| Mar 17 22:34:13 | M50699483 15000000 0x2ee5c7cc8f97b0b9 | 2688K 0.25000 2.0264 101.32s | 20:08:50 29.58% |
| Mar 17 23:08:00 | M50699483 16000000 0x42acbd803c14864f | 2688K 0.26563 2.0265 101.32s | 19:34:48 31.55% |
| Mar 17 23:41:52 | M50699483 17000000 0x693f9e609d94f89e | 2688K 0.28125 2.0333 101.66s | 19:00:57 33.53% |
| Mar 18 00:15:45 | M50699483 18000000 0x91713add0ed97c33 | 2688K 0.25000 2.0318 101.59s | 18:27:08 35.50% |
| Mar 18 00:49:38 | M50699483 19000000 0x277a592c42facb53 | 2688K 0.28125 2.0330 101.65s | 17:53:19 37.47% |
| Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done |
| Mar 18 01:23:30 | M50699483 20000000 0xa5682a939ef38d9a | 2688K 0.25000 2.0328 101.64s | 17:19:29 39.44% |
| Mar 18 01:57:23 | M50699483 21000000 0x8a8b4492ffc5470b | 2688K 0.25391 2.0321 101.60s | 16:45:39 41.42% |
| Mar 18 02:31:15 | M50699483 22000000 0xd6d3f91689ddfaf1 | 2688K 0.25000 2.0314 101.57s | 16:11:48 43.39% |
| Mar 18 03:05:07 | M50699483 23000000 0xb48ac590fba75fe2 | 2688K 0.25000 2.0317 101.58s | 15:37:57 45.36% |
| Mar 18 03:38:59 | M50699483 24000000 0xad49e3830b9218d2 | 2688K 0.25342 2.0319 101.59s | 15:04:05 47.33% |
| Mar 18 04:12:51 | M50699483 25000000 0xe4382fb2661b845a | 2688K 0.28125 2.0279 101.39s | 14:30:14 49.31% |
| Mar 18 04:46:38 | M50699483 26000000 0x83c74046877bc1d7 | 2688K 0.25781 2.0262 101.31s | 13:56:17 51.28% |
| Mar 18 05:20:25 | M50699483 27000000 0xeb4330b282026832 | 2688K 0.26563 2.0264 101.32s | 13:22:22 53.25% |
| Mar 18 05:54:15 | M50699483 28000000 0x54a4f4caadaae0f9 | 2688K 0.26563 2.0313 101.56s | 12:48:30 55.22% |
| Mar 18 06:28:07 | M50699483 29000000 0x9259066017b75695 | 2688K 0.31250 2.0316 101.58s | 12:14:39 57.19% |
| Mar 18 07:01:59 | M50699483 30000000 0xfcee9793433d6108 | 2688K 0.25000 2.0309 101.54s | 11:40:47 59.17% |
| Mar 18 07:35:50 | M50699483 31000000 0x0082df9e0893d9d2 | 2688K 0.25000 2.0313 101.56s | 11:06:56 61.14% |
| Mar 18 08:09:39 | M50699483 32000000 0x9b2d2709d0339c17 | 2688K 0.28125 2.0253 101.26s | 10:33:03 63.11% |
| Mar 18 08:43:25 | M50699483 33000000 0x7a2717061965634c | 2688K 0.25000 2.0253 101.26s | 9:59:09 65.08% | Ernst's run matched to 33.13M and earlier
| Mar 18 09:17:11 | M50699483 34000000 0xa22077a84ffa1c25 | 2688K 0.26563 2.0254 101.27s | 9:25:15 67.06% | Ernst's run mismatches by 33.14M and onward
| Mar 18 09:50:57 | M50699483 35000000 0x3724fb6212e2582c | 2688K 0.28125 2.0253 101.26s | 8:51:22 69.03% |
| Mar 18 11:05:58 | M50699483 36000000 0x37b839cd056612f1 | 2688K 0.26563 2.0287 101.43s | 8:17:29 71.00% |
| Mar 18 11:39:47 | M50699483 37000000 0x0cbae6ba6e70a9cd | 2688K 0.26563 2.0283 101.41s | 7:43:38 72.97% |
| Mar 18 12:13:37 | M50699483 38000000 0x8c7564c5791e9f0c | 2688K 0.28125 2.0291 101.45s | 7:09:47 74.95% |
| Mar 18 12:47:27 | M50699483 39000000 0x2370560da2daf81d | 2688K 0.25000 2.0296 101.48s | 6:35:56 76.92% |
| Mar 18 13:21:17 | M50699483 40000000 0x30e2d45c4779c59d | 2688K 0.25781 2.0300 101.50s | 6:02:06 78.89% |
| Mar 18 13:55:08 | M50699483 41000000 0xa9554a0bd7a1a189 | 2688K 0.28125 2.0307 101.53s | 5:28:15 80.86% |
| Mar 18 14:29:00 | M50699483 42000000 0x63e3f73e9f80d7e7 | 2688K 0.26563 2.0310 101.55s | 4:54:25 82.84% |
| Mar 18 15:04:07 | M50699483 43000000 0x71c2bd796b14659d | 2688K 0.25000 2.0267 20.26s | 4:20:37 84.81% |
| Mar 18 15:40:30 | M50699483 44000000 0xb2471a858f2cf03c | 2688K 0.25000 2.0294 20.29s | 3:46:47 86.78% |
| Mar 18 16:14:19 | M50699483 45000000 0x962d7ea1b99c8cdd | 2688K 0.24219 2.0296 20.29s | 3:12:55 88.75% |
| Mar 18 16:48:08 | M50699483 46000000 0xb4f6cda6c171dd1d | 2688K 0.23438 2.0274 20.27s | 2:39:04 90.73% |
| Mar 18 17:21:56 | M50699483 47000000 0xb931cec9f7648e5e | 2688K 0.25000 2.0276 20.27s | 2:05:13 92.70% |
| Mar 18 17:55:45 | M50699483 48000000 0x97af7a930201bf89 | 2688K 0.26563 2.0279 20.27s | 1:31:22 94.67% |
| Mar 18 18:29:33 | M50699483 49000000 0xf839104523ba25f8 | 2688K 0.25000 2.0273 20.27s | 57:31 96.64% |
| Mar 18 19:03:21 | M50699483 50000000 0xc46cbefb9833ef5f | 2688K 0.28125 2.0272 20.27s | 23:40 98.62% |
M( 50699483 )C, 0x534e6375ec291d92, offset = 25360009, n = 2688K, CUDALucas v2.06beta[/CODE]final res64s from primenet, [URL]https://www.mersenne.org/report_exponent/?exp_lo=50699483&exp_hi=&full=1[/URL][CODE]
status date user res64 shift reliability
[COLOR=Green]Verified 2011-02-16 Stephan Grupp 534E6375EC291D92 43987345 matched[/COLOR]
[COLOR=DarkRed]Bad 2020-03-17 Ernst W. Mayer AC42E090D0368236 4377830 mismatched interim residues, see above
[/COLOR][COLOR=green]Verified 2020-03-19 Kriesel 534E6375EC291D92 25360009 matched
[/COLOR][/CODE]

ewmayer 2020-03-19 20:24

I've verified that my DC run went off the rails between iterations 33.13M and 33.14M:

Original DC run:
[code][2020-03-03 21:06:14] M50699483 Iter# = 33130000 Res64: DBEC805AFE89F02C. AvgMaxErr = 0.071080518. MaxErr = 0.109375000. shift = 26304104.
M50699483 Roundoff warning on iteration 33139667, maxerr = 0.500000000000
Retrying iteration interval to see if roundoff error is reproducible.
Restarting M50699483 at iteration = 33130000. Res64: DBEC805AFE89F02C, residue shift count = 26304104
M50699483: using FFT length 2816K = 2883584 8-byte floats, initial residue shift count = 26304104
this gives an average 17.582107197154652 bits per digit
Retry of iteration interval with fatal roundoff error was successful.
[2020-03-03 21:23:43] M50699483 Iter# = 33140000 Res64: 3FE1873AE0CFDBAD. AvgMaxErr = 0.071077051. [b]MaxErr = 0.160156250[/b]. shift = 10073663.
[2020-03-03 21:32:33] M50699483 Iter# = 33150000 Res64: 68D413A52601DAB7. AvgMaxErr = 0.071095947. MaxErr = 0.101562500. shift = 12690212.[/code]
Re-run:
[code][2020-03-18 22:17:32] M50699483 Iter# = 33130000 Res64: DBEC805AFE89F02C. AvgMaxErr = 0.071080518. MaxErr = 0.109375000. shift = 26304104.
[2020-03-18 22:19:46] M50699483 Iter# = 33140000 Res64: 067C546DA1F13507. AvgMaxErr = 0.071065967. [b]MaxErr = 0.109375000[/b]. shift = 10073663.
[2020-03-18 22:22:00] M50699483 Iter# = 33150000 Res64: 1CD84913571585E1. AvgMaxErr = 0.071029297. MaxErr = 0.109375000. shift = 12690212.[/code]
So a surmise at what happened with the first run:

1. Detect some kind of residue data corruption at iteration 33139667, manifesting itself with a sudden fatal (and far larger than the ROE range for this p as established by first part of run) maxerr = 0.5;

2. Restart for the iter-33.13M savefile - note the Res64 matches that of the re-run from 33M - and this time the 10Kiter interval completes successfully (no dangerous ROEs), but whatever glitchiness/system-needs-reboot-ness hosed the initial run of the interval is still happening, just this time it corrupted the data in a way that evaded the ROE - but the max ROE is still anomalously high, see my comparative bolding of the 33.14Miter max ROE above - we get max ROE ~0.16, it only reverts to the normal-for-this run of ~0.10 on the ensuing iteration interval. Trouble is, that is likely an unreliable guide - one more reason to use PRP/Gerbicz, especially on flaky hardware.

More thoughts on way GIMPS might better handle such erroneous runs - we know the server saving actual interim savefiles is not an option. But there are low-bandwidth ways to store interim refernce data for DCers to use to see if their runs are on track. The every-1M-iter cross-comparison is the model here:

1. All GIMPS clients agree on "iteration 0" convention, and that every 1M iterations (at least) codes will report in interim unshifted Res64;

2. When sending first-run results to the server, clients now also send said list of Res64 - that amounts to < 2kB data for current wavefront runs;

3. DCers obtain a copy of said data when they are assigned the exponent. Client programs would use those much like they currently use the Gerbicz check for PRP runs.

LaurV 2020-03-30 04:08

[QUOTE=Runtime Error;541247]My question: is this working as intended?[/QUOTE]
[QUOTE=phillipsjk;541257]Sounds like a bug. This may be vulnerable to a replay attack, since you will have access to the full residues.[/QUOTE]
It works as intended.

You are ok, right now I assume no action will be taken as long as you don't continue to do that. Sometimes we need triple and quadruple checks for "suspect" results (and there are ways to identify such, behind of what you see on the web), and it should be normal that people who do TC/QC tests get their credits.

On the other hand, if somebody tries to "inflate his credits" by repeatedly doing tricks like that, he will be very fast spotted by the wolves lurking here around (I mean human wolves, not bots :razz:) who have nothing to do all day but watching what other users do (this is said with no disrespect!).

In general, fast advancing in tops is immediately spotted by somebody, and the fast runner will be dissected not only with the scalpel, but mostly with a handsaw too, hehe. We are kind of a "tough community" here. In the good sense, of course. In the past, when such profiteers were found, George used to adjust their credits into the negatives, so whoever tried to take advantage of the system would have to work for some weeks to reach zero, and start fresh again. So, beware :smile:

Runtime Error 2020-03-30 16:36

[QUOTE=LaurV;541304]It works as intended. [/QUOTE]

Good to know, thanks!

kriesel 2020-03-31 15:29

[QUOTE=ATH;535506]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][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][/QUOTE]
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-03-31 15:42

[QUOTE=kriesel;541404]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][/QUOTE]
This is not a commentary thread. If you want to add info to the quoted post, send me a pm with the specific changes or an new version of that post. Your post that I have quoted will be moved or wished away into the cornfield.


All times are UTC. The time now is 00:57.

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