processed dc and tc posts

[kriesel]

Originally Posted by ewmayer

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.

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]

Originally Posted by Uncwilly

[2020-02-13 23:10:28] M50699483 Iter# =  6000000  Res64: 0C3E78B1C77FA688. shift: 33080656

[Mar 18 14:19] M50699483 interim LL residue AF0BF1AEDBD6D468 at iteration 6000000

I guess my shift is not zero.

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]

Originally Posted by Uncwilly

[2020-02-13 23:10:28] M50699483 Iter# =  6000000  Res64: 0C3E78B1C77FA688. shift: 33080656

[Mar 18 14:19] M50699483 interim LL residue AF0BF1AEDBD6D468 at iteration 6000000

I guess my shift is not zero.

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₀=4, s_n+1=(s_n²-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]

Originally Posted by kriesel

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₀=4, s_n+1=(s_n²-2) mod Mp.

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]

Originally Posted by kriesel

If using prime95 or mprime, there's an option to print 3 successive residues.

Originally Posted by ewmayer

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.

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]

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

|   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

final res64s from primenet, https://www.mersenne.org/report_expo...exp_hi=&full=1

status         date          user           res64               shift          reliability
Verified    2011-02-16    Stephan Grupp    534E6375EC291D92    43987345    matched
Bad         2020-03-17    Ernst W. Mayer   AC42E090D0368236    4377830     mismatched interim residues, see above
Verified    2020-03-19    Kriesel          534E6375EC291D92    25360009    matched

[ewmayer]

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

Original DC run:

[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. MaxErr = 0.160156250. shift = 10073663.
[2020-03-03 21:32:33] M50699483 Iter# = 33150000 Res64: 68D413A52601DAB7. AvgMaxErr = 0.071095947. MaxErr = 0.101562500. shift = 12690212.

Re-run:

[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. MaxErr = 0.109375000. shift = 10073663.
[2020-03-18 22:22:00] M50699483 Iter# = 33150000 Res64: 1CD84913571585E1. AvgMaxErr = 0.071029297. MaxErr = 0.109375000. shift = 12690212.

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]

Originally Posted by Runtime Error

My question: is this working as intended?

Originally Posted by phillipsjk

Sounds like a bug. This may be vulnerable to a replay attack, since you will have access to the full residues.

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

[Runtime Error]

Originally Posted by LaurV

It works as intended.

Good to know, thanks!

[kriesel]

Originally Posted by ATH

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 * 2^96365519 - 1
76: Trial factored to 2⁷⁶
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?)
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.

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

[Uncwilly]

Originally Posted by kriesel

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

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.