[QUOTE=LookAS;477571]I tried benchmarking dual Xeon E5-2690v3 in 29.4b7 and it crashed as well.[/QUOTE]

I'll admit, I run a lot of dual Xeons but I haven't done a benchmark run in ages.

I just started a benchmark run on a dual E5-2690v4 system... so far no crashes.

I should note that in my local.txt file I have specific worker affinity setup. I don't know if the benchmark pays attention to that like an actual worker, but perhaps the crash is coming from some core detection routine?

Here's what the relevant portion of the local.txt looks like (I have the first core in each worker be the 2nd physical one on purpose, because I think that's used for the main thread and the rest are helpers... having the main thread be something besides the first core may be helpful to prevent normal OS stuff from having the extra contention):

[CODE]WorkerThreads=2
CoresPerTest=14
NumPhysicalCores=28

[Worker #1]
Affinity=2,0,4,6,8,10,12,14,16,18,20,22,24,26

[Worker #2]
Affinity=30,28,32,34,36,38,40,42,44,46,48,50,52,54[/CODE]

With that as a guide, you can kind of figure out the numbering scheme and adjust for chips with more/less cores. Windows core numbering will alternate "physical" and hyperthread cores (i.e. the first core will be numbered 0 and 1). I think Linux does it different where all the "physical" cores are first and then come all the HT cores. So on a 4 core system, 0-3 are physical and 4-7 are hyperthread. I could be wrong on the Linux numbering, but Windows definitely works by alternating physical/HT cores.

Is it anticipated, that mprime running ECM-CF on small Mersenne numbers (M1xxx B1=2.9e9) runs only on a single thread, even though I've set the configuration to 1 worker and 4 threads?

Ah, I guess there is no ECM-CF possible for manual assignments, only ECM.

Not sure if it fits in here, but is it possible to run p-1 for a number like that: 10^75005*8-7?
How would the worktodo look like, if it works?

[QUOTE=MisterBitcoin;478050]Not sure if it fits in here, but is it possible to run p-1 for a number like that: 10^75005*8-7?
How would the worktodo look like, if it works?[/QUOTE]

Try Pminus1=8,10,75005,-1,B1,B2 where B1 and B2 are the P-1 bounds you want to try.

[QUOTE=Prime95;478052]Try Pminus1=8,10,75005,-1,B1,B2 where B1 and B2 are the P-1 bounds you want to try.[/QUOTE]

Thanks. That worked well. I need some time, but pepi was there to help me.

This is probably a stupid question, but is the current version of Prime95 still limited to 64 threads?

[QUOTE=ixfd64;478999]This is probably a stupid question, but is the current version of Prime95 still limited to 64 threads?[/QUOTE]

I think the limit was increased to 512 or 1024.

That's pretty awesome.

This reminds me: now that there are much more users with access to many-core systems, are there any plans to make the UI less clunky when the user is running a large number of worker windows?

Here's an example of a user running 64 threads: [url]http://mersenneforum.org/showthread.php?t=16865[/url]

Therefore, I have two suggestions:
[LIST=1][*][url=http://mersenneforum.org/showpost.php?p=244346&postcount=5]Make the status window scrollable[/url] so that it doesn't stretch off the screen.[*]Make the main MDI scrollable so that the worker windows aren't squished together.[/LIST]
Would these be very hard to implement?

[QUOTE=ixfd64;479033]

Therefore, I have two suggestions:
[LIST=1][*][url=http://mersenneforum.org/showpost.php?p=244346&postcount=5]Make the status window scrollable[/url] so that it doesn't stretch off the screen.[*]Make the main MDI scrollable so that the worker windows aren't squished together.[/LIST]
Would these be very hard to implement?[/QUOTE]

I have no idea. I've barely touched the Windows UI code in a decade. I've added it to my to-do list for the next release.

Build 8 now available for download from [url]ftp://mersenne.org/gimps[/url]. Windows and Linux 64-bit only.

Two changes (compare to build 7):

1) Fixes bug where autobench interrupts a torture test.
2) Linked with hwloc 1.11.9. Fixes a crash bug on a new unreleased CPU.

I've noticed that my [c]results.txt[/c] file for [I]some[/I] computers contain seemingly random benchmark information.

[QUOTE][Wed Jan 24 18:02:03 2018]
FFTlen=4608K, Type=3, Arch=4, Pass1=384, Pass2=12288, clm=4 (2 cores, 2 workers): 78.46, 79.98 ms. Throughput: 25.25 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=384, Pass2=12288, clm=2 (2 cores, 2 workers): 48.23, 47.87 ms. Throughput: 41.62 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=384, Pass2=12288, clm=1 (2 cores, 2 workers): 44.51, 41.41 ms. Throughput: 46.61 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=512, Pass2=9216, clm=4 (2 cores, 2 workers): 42.91, 41.93 ms. Throughput: 47.15 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=512, Pass2=9216, clm=2 (2 cores, 2 workers): 41.96, 41.84 ms. Throughput: 47.73 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=512, Pass2=9216, clm=1 (2 cores, 2 workers): 42.82, 41.41 ms. Throughput: 47.50 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=768, Pass2=6144, clm=4 (2 cores, 2 workers): 42.37, 40.14 ms. Throughput: 48.51 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=768, Pass2=6144, clm=2 (2 cores, 2 workers): 40.12, 39.99 ms. Throughput: 49.94 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=768, Pass2=6144, clm=1 (2 cores, 2 workers): 41.02, 39.69 ms. Throughput: 49.58 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=1024, Pass2=4608, clm=4 (2 cores, 2 workers): 43.23, 41.00 ms. Throughput: 47.52 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=1024, Pass2=4608, clm=2 (2 cores, 2 workers): 40.03, 38.45 ms. Throughput: 50.99 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=1024, Pass2=4608, clm=1 (2 cores, 2 workers): 39.70, 39.33 ms. Throughput: 50.62 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=1536, Pass2=3072, clm=4 (2 cores, 2 workers): 43.69, 41.30 ms. Throughput: 47.10 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=1536, Pass2=3072, clm=2 (2 cores, 2 workers): 41.07, 38.47 ms. Throughput: 50.34 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=1536, Pass2=3072, clm=1 (2 cores, 2 workers): 58.20, 52.47 ms. Throughput: 36.24 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=2048, Pass2=2304, clm=4 (2 cores, 2 workers): 94.20, 88.56 ms. Throughput: 21.91 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=2048, Pass2=2304, clm=2 (2 cores, 2 workers): 66.01, 63.22 ms. Throughput: 30.97 iter/sec.
FFTlen=4608K, Type=3, Arch=4, Pass1=2048, Pass2=2304, clm=1 (2 cores, 2 workers): 43.09, 41.50 ms. Throughput: 47.31 iter/sec.
[/QUOTE]

If these are the automatic benchmarks introduced two versions ago, then shouldn't they be written to [c]gwnum.txt[/c] instead?

gwum.txt contains a highly encoded version of the same data

[QUOTE=Prime95;480471]gwum.txt contains a highly encoded version of the same data[/QUOTE]

That makes sense. Thanks.

Hello, I have been unable to get AVX2 support to work in the latest prime95 or even earlier versions. Defaults to FMA3. Disabling FMA3 makes it revert to AVX. Disabling AVX makes it use old traditional FFTs like core2, pentium4, etc. However I have been unable to get AVX2 to work directly. The switch CPUSupportsAVX2=1 does nothing. It's either FMA3, AVX, or traditional.

Using 7820HK CPU on a MSI Throttlebook ;)
Windows 10 Enterprise.

Any ideas? (HWinfo64 shows full AVX2 support).

Stress testing only.

[QUOTE=Falkentyne;481488]Hello, I have been unable to get AVX2 support to work in the latest prime95 or even earlier versions. Defaults to FMA3.[/QUOTE]

This is normal. FMA3 is part of AVX2, in fact it is the only AVX2 instruction that prime95 uses.

I have a possible bug report and a suggestion.

1. I've noticed that save files are not automatically deleted when the user completes an assignment started via the Advanced menu. This is true for at least P-1 assignments. Is this intentional?

2. I prefer that the automatic benchmark data do not clutter up my [c]results.txt[/c] file. Could we get the option to dump the data to another file instead? I could manually split my [c]results.txt[/c] file but am not sure if Prime95 relies on [c]results.txt[/c] to get the benchmark data it needs.

If I recall, it was intentional to not delete P-1 saves to allow easy continuation to higher bounds (e.g. if no [new] factor was found).
I would also prefer to see benchmarks split to [i]benchmarks.txt[/i] or similar instead of cluttering up [i]results.txt[/i]

[QUOTE=ixfd64;481564] I prefer that the automatic benchmark data do not clutter up my [c]results.txt[/c] file. Could we get the option to dump the data to another file instead? I could manually split my [c]results.txt[/c] file but am not sure if Prime95 relies on [c]results.txt[/c] to get the benchmark data it needs.[/QUOTE]

I'll add that to my todo list for the next release.

Prime95 does not read benchmark data stored in results.txt -- it is safe to delete it or move it to a separate file.

[QUOTE=Prime95;481507]This is normal. FMA3 is part of AVX2, in fact it is the only AVX2 instruction that prime95 uses.[/QUOTE]

Correction. Some trial factoring code can use other AVX2 instructions. This does not affect stress testing.

[QUOTE=Prime95;481567]Prime95 does not read benchmark data stored in results.txt -- it is safe to delete it or move it to a separate file.[/QUOTE]

Thanks for the information. I've split my [c]results.txt[/c] file - it looks a lot cleaner now!

Hi, I installed today version 29.4 build 8 on my Debian Linux machine and I wanted to set it to run in mode 154. However it just told me that this mode is invalid:

[Comm thread Mar 26 14:26] RESPONSE:
[Comm thread Mar 26 14:26] pnErrorResult=0
[Comm thread Mar 26 14:26] pnErrorDetail=Invalid work preference: 154. Using de fault work preference instead.
[Comm thread Mar 26 14:26] Server assigned Lucas Lehmer primality double-check w ork.

Any suggestions? In the prime.txt I can see that the work preference is set to 154.

There is no work preference 154.

[CODE]0 - Whatever makes the most sense
1 - Trial factoring to low limits
2 - Trial factoring
4 - P-1 factoring
5 - ECM for first factor on Mersenne numbers
6 - ECM on Fermat numbers
8 - ECM on mersenne cofactors
100 - First time primality tests
101 - Double-checking
102 - World record primality tests
104 - 100M digit number to LL test (not recommended)
150 - First time PRP tests (Gerbicz)
151 - Doublecheck PRP tests (Gerbicz)
152 - World record sized numbers to PRP test (Gerbicz)
153 - 100M digit number to PRP test (Gerbicz)
160 - PRP on Mersenne cofactors
161 - PRP double-checks on Mersenne cofactors
[/CODE]

[QUOTE=Prime95;481507]This is normal. FMA3 is part of AVX2, in fact it is the only AVX2 instruction that prime95 uses.[/QUOTE]

The VIA Isiah C4650 supports AVX and AVX2. But not FMA3.

Not that anybody will actually use that processor for prime though...

Hi ATH,
my menu looks different. This is the one of my version:

Use the following values to select a work type:
0 - Whatever makes the most sense
100 - First time LL tests
102 - World record LL tests
101 - Double-check LL tests
150 - First time PRP tests
152 - World record PRP tests
151 - Double-check PRP tests
2 - Trial factoring
4 - P-1 factoring
154 - 100 million digit PRP tests
104 - 100 million digit LL tests (not recommended)
160 - First time PRP on Mersenne cofactors
161 - Double-check PRP on Mersenne cofactors
5 - ECM for first factors of Mersenne numbers
8 - ECM on Mersenne cofactors
6 - ECM on Fermat numbers
1 - Trial factoring to low limits

It tells me that there is no 153, but a 154 instead....

That's a bug in the linux menus. Change your work preference to 153 and all should be good.

[QUOTE=Prime95;483459]That's a bug in the linux menus. Change your work preference to 153 and all should be good.[/QUOTE]

I don't see 153 anywhere in that list. :smile:

[QUOTE=chalsall;483464]I don't see 153 anywhere in that list. :smile:[/QUOTE]
[CODE]153 - 100M digit number to PRP test (Gerbicz)[/CODE]
I am probably missing the joke.

[QUOTE=kladner;483493][CODE]153 - 100M digit number to PRP test (Gerbicz)[/CODE]
I am probably missing the joke.[/QUOTE]

No joke, just your garden-variety reading comprehension #fail.

Hi,

for me the 153 seem to work! Thanks for that! :smile:

On one of my computers, a few of the benchmarks show INF ms. Is this normal?

[QUOTE=ixfd64;485170]On one of my computers, a few of the benchmarks show INF ms. Is this normal?[/QUOTE]

No. It's a complete mystery -- at least you are not alone. You can commiserate with xyzzy.

[QUOTE=Prime95;485192]No. It's a complete mystery -- at least you are not alone. You can commiserate with xyzzy.[/QUOTE]

Thanks for the response. If the benchmarks show invalid values, am I more likely to get incorrect results?

For the record, this computer did recently find a P-1 factor, but this probably isn't too useful because the minimum required B1 was less than 100,000. At any rate, I'm also running two double checks, although they're going to take a while to complete as the computer has a relatively old Q9400 processor.

[QUOTE=ixfd64;485193]Thanks for the response. If the benchmarks show invalid values, am I more likely to get incorrect results?[/QUOTE]

No, the bug seems to be completely related to timing an interval. Probably the Windows HighResTimer calls.

The software was recently modified to send interim residues at various milestones: 500K, 5M, 10M, etc. There seems to be a bug with that functionality.

I am doing PRP-CF for exponents in the 8.0M range, and these were manually added to the worktodo file with assignment IDs set to "N/A".

Here are some selected lines from prime.log:

[CODE]
[Mon Apr 23 15:01:45 2018 - ver 29.4]
Sending interim residue 500001 for M8047909
[Mon Apr 23 15:52:17 2018 - ver 29.4]
Sending interim residue 5000001 for M8047909
Sending result to server: UID: GP2/c5.xlarge, M8047909/known_factors is not prime. Type-5 RES64: ...

[Mon Apr 23 17:52:21 2018 - ver 29.4]
Sending interim residue 500001 for M8048069
[B]Sending interim residue 5000001 [COLOR="Red"]for M8050103[/COLOR][/B]
Sending result to server: UID: GP2/c5.xlarge, M8048069/known_factors is not prime. Type-5 RES64: ...

[Mon Apr 23 19:52:50 2018 - ver 29.4]
Sending interim residue 500001 for M8050103
Sending interim residue 5000001 for M8050103
Sending result to server: UID: GP2/c5.xlarge, M8050103/known_factors is not prime. Type-5 RES64: ...
[/CODE]

And lines from results.txt:

[CODE]
[Mon Apr 23 15:52:17 2018]
{"status":"C", "exponent":8047909, ...}
[Mon Apr 23 17:52:20 2018]
{"status":"C", "exponent":8048069, ...}
[Mon Apr 23 19:52:50 2018]
{"status":"C", "exponent":8050103, ...}
[/CODE]

As we can see, the interim residues usually don't get sent right away, instead they sit in prime.spl and get sent later. In particular the 5M (= 5000001) interim residues are only getting sent when the exponent itself completes. This delay may be intentional, but it might be related to the following bug:

At 17:52:21, when it says it's sending the 5M (= 5000001) interim residue for M8050103, that clearly ought to be the 5M interim residue for M8048069 instead. The exponent M8050103 had only just started at that point, and indeed that's when I noticed it and wondered how the program could send an interim residue it hadn't even calculated yet.

[B]At the very least, the log file recorded the wrong exponent; however it seems quite plausible that the interim residue sent to the server was also associated with the wrong exponent.[/B]

The problem might also be associated with the fact that these 8.0M exponents had no assignment IDs. However, there is some additional weirdness regarding that latter point, see the next message.

Earlier I was doing PRP-CF for exponents in the 7.7M range. Unlike the 8.0M exponents, these were assigned automatically and had assignment IDs.

There is the minor oddity that sometimes the 5M (= 5000001) interim residue is logged with the exponent itself, and other times with the assignment id. I wonder if there's any reason for the inconsistency, or if that's related to the bug in the previous message.

[CODE]
[Sun Apr 22 23:57:34 2018 - ver 29.4]
Sending interim residue 500001 for M7704127
Sending interim residue 5000001 for [B][COLOR="Red"]assignment 413EFCC136707FC6A40991B97F396D8E[/COLOR][/B]
Sending result to server: UID: GP2/c5.xlarge, M7704127/1886784765808106376319 is not prime. Type-5 RES64: ..., AID: 413EFCC136707FC6A40991B97F396D8E

[Mon Apr 23 01:36:56 2018 - ver 29.4]
Sending interim residue 500001 for M7704623
Sending interim residue 5000001 for M7704623
Sending result to server: UID: GP2/c5.xlarge, M7704623/1719170205596471 is not prime. Type-5 RES64: ..., AID: 3FF8382668A26ACECF68585E300F7FCC

[Mon Apr 23 03:01:45 2018 - ver 29.4]
Sending interim residue 500001 for M7705003
Sending interim residue 5000001 for M7705003

[Mon Apr 23 03:16:36 2018 - ver 29.4]
Sending result to server: UID: GP2/c5.xlarge, M7705003/63196434607/407313780520639 is not prime. Type-5 RES64: ..., AID: 2DF0093B273EF03203CE51CF65CF23BC

[Mon Apr 23 04:56:17 2018 - ver 29.4]
Sending interim residue 500001 for M7705219
Sending interim residue 5000001 for [B][COLOR="Red"]assignment 21EF1DBA9D2319BE1EA7CF7074398CFE[/COLOR][/B]
Sending result to server: UID: GP2/c5.xlarge, M7705219/3837199063/373810994567 is not prime. Type-5 RES64: ..., AID: 21EF1DBA9D2319BE1EA7CF7074398CFE
[/CODE]

As mentioned earlier, the interim residues don't get sent right away, instead they sit in a prime.spl file and only get sent at a later point. In particular the 5M (= 5000001) interim residues are usually only getting sent when the exponent itself completes.

I wonder if all the 5M (= 5000001) interim residues were received correctly by the server, regardless of whether they were logged by exponent or by assignment ID.

Jacobi check and battery
 

Hello, i noticed something about the battery mode - [I]program set to not run while on battery[/I]:
if the laptop is unplugged, it will still run the Jacobi check [I](and slower, since it is saving power)[/I], then stops as soon as it "starts" the exponent.
(Doesn't matter if prime95 runs as a startup, or resumes after a pause.)

[QUOTE=GP2;486026][B]At the very least, the log file recorded the wrong exponent; however it seems quite plausible that the interim residue sent to the server was also associated with the wrong exponent.[/B][/QUOTE]

This is happening fairly often.

For example I'm running triple-check LL tests in the 2M range just for fun, and there are hundreds of examples of the above bug.

For instance:

[CODE]
[Sun May 06 17:47:58 2018 - ver 29.4]
Sending interim residue 500000 [B][COLOR="Red"]for M2331421[/COLOR][/B]
Sending result to server: UID: GP2/old, M2331379 is not prime. Res64: ...

PrimeNet success code with additional info:
LL result matches previously verified M2331379 --
CPU credit is 0.1575 GHz-days.



[Sun May 06 18:03:14 2018 - ver 29.4]
Sending interim residue 500000 for M2331421
Sending result to server: UID: GP2/old, M2331421 is not prime. Res64: ...

PrimeNet success code with additional info:
LL result matches previously verified M2331421 --
CPU credit is 0.1575 GHz-days.
[/CODE]


Once again, the interim residue result is not sent immediately, but rather is stored in prime.spl and only gets sent when the LL test completes, and a new LL test starts.

When this happens, prime.log sometimes records the wrong exponent. The first "Sending interim residue" line above should state that it's for M2331379, not M2331421.

Is this error only present in the logging within prime.log, or is the wrong exponent actually being sent to Primenet?

Can we check if Primenet recorded two different interim residues for 500000 for M2331421, and none for M2331379? If so, there could be a lot of bad interim residues in the database by now.

I've added the interim residues bug to my to-do list. I'm buried in AVX512 development right now so I won't get to it soon. Anyway, the server isn't using interim residues right now and for LL tests which take several days, the server should be getting several good interim residues per LL test.

[QUOTE=Prime95;487103]I've added the interim residues bug to my to-do list. I'm buried in AVX512 development right now so I won't get to it soon. Anyway, the server isn't using interim residues right now and for LL tests which take several days, the server should be getting several good interim residues per LL test.[/QUOTE]

Under what circumstances do results get buffered into a prime.spl file rather than being sent to Primenet immediately? I wonder if this occasionally happens for final LL residues and not just for interim residues.

[QUOTE=GP2;487159]Under what circumstances do results get buffered into a prime.spl file rather than being sent to Primenet immediately? I wonder if this occasionally happens for final LL residues and not just for interim residues.[/QUOTE]

Important messages are sent immediately. Interim residues are spooled for later (the daily checkin). So the bug could be affecting the last interim LL residue.

Is it possible to do trial factoring on non-base 2 numbers e.g. 3^p+-1 using Prime95? Thanks.

[QUOTE=Citrix;487390]Is it possible to do trial factoring on non-base 2 numbers e.g. 3^p+-1 using Prime95? Thanks.[/QUOTE]

Um, no. There should be several good sievers out there that do what you need.

Unfortunately there aren't any.

srxsieve does k*b^n+-1. You want k = 1, no?
Not sure if sr1sieve will do +1 and -1 at the same time; you might have to run two instances.
Or do you mean sieve the cofactors after dividing out all the evens?

[QUOTE=VBCurtis;487399]srxsieve does k*b^n+-1. You want k = 1, no?
Not sure if sr1sieve will do +1 and -1 at the same time; you might have to run two instances.
Or do you mean sieve the cofactors after dividing out all the evens?[/QUOTE]

These numbers have the same(-ish) factor restrictions (2kp+1) as Mersennes, and hence should be TF-ed, not sieved. Mfaktc could be modified to handle these, I guess, with a little bit of work. IIRC, mfaktc was already modified to handle Wagstaff numbers ((2^p+1)/3).

EDIT:- The rule seems to be f = 1 or 7 (mod 12) for (3^p+1)/4, and f = 1 or 11 (mod 12) for (3^p-1)/2

How can I manually do a PRP-CF?

[QUOTE=heliosh;487427]How can I manually do a PRP-CF?[/QUOTE]

At present, the only way is to get PRP-CF assignments using prime95/mprime.

You could configure a prime95 with an internet connection to get several weeks ow PRP-CF work and then move the worktodo.txt file to your target machine.

[QUOTE=heliosh;487427]How can I manually do a PRP-CF?[/QUOTE]

I do this, but it's a bit tricky and you have to know what you're doing.

You can create worktodo lines in the appropriate format, filling in the appropriate known-factor strings, and daily monitoring new factor discoveries in order to do any necessary updates.

If you are doing double-checks, you have to tailor it further to make sure you're matching the residue type of the previous result (Type 1 or Type 5).

It's tedious to fill in the lists of factors by hand, it's best to automate that part.

Is there a particular exponent or range of exponents that you wanted to do?

[QUOTE=GP2;487433]
Is there a particular exponent or range of exponents that you wanted to do?[/QUOTE]
Just the exponents for which I found a factor. (For example M8929 right now)

It is assigned to Oliver Kruse automatically, but since it needs 2 tests, you can run this line in worktodo for a type 5 test:
PRP=N/A,1,2,8929,-1,99,0,3,5,"196439,2555359872029449,1115430961341245177793296572392840751"

Ok, thanks.

[QUOTE=heliosh;487435]Just the exponents for which I found a factor. (For example M8929 right now)[/QUOTE]

If it's a small exponent like that, then mprime itself will do an instant PRP test and output " is a probable prime!" if applicable, in the results.txt file.

This works at least up to the low 20K range. Unfortunately, that instant PRP test result isn't sent to Primenet.

An alternative is to go to [url]http://factordb.com[/url], enter "M8929" into the search box, then enter your new factor into the "Report factors" box, then click on the red link to the new cofactor. Usually factordb will do a quick automatic PRP test for such small cofactors.

Hello everyone!


Could there be a bug in the 64-bit linux build?


I've got errors of this form:


[QUOTE]
FATAL ERROR: Rounding was 0.4846425222, expected less than 0.4
Hardware failure detected, consult stress.txt file.

[/QUOTE]


The checksum of the download is correct.


Where can I find core dumps?

[QUOTE=soeglii;488444]Hardware failure detected, consult stress.txt file.[/QUOTE]Is your system overclocked? Or otherwise overheating?

This version comes with time between network retries set at 70 minutes. I sometimes unplug the network cable, mprime retries every 2 minutes to contact the server. I've set the network retries at 60 and at 120 minutes. It stores and reports those values but still retries every 2 minutes.

Can someone reproduce this with mprime current version?

[QUOTE=tha;489806]This version comes with time between network retries set at 70 minutes. I sometimes unplug the network cable, mprime retries every 2 minutes to contact the server. I've set the network retries at 60 and at 120 minutes. It stores and reports those values but still retries every 2 minutes.

Can someone reproduce this with mprime current version?[/QUOTE]

Yes. It would seem that if network itself is not connected (LAN disconnected / wireless off), it would try every 2 minutes. The retry value is only considered if network connection is there, but site is not reachable (bad internet connection, site down, etc.).

I don't think this behavior is consistent with Windows version.

[QUOTE=soeglii;488444]I've got errors of this....[/QUOTE]You should use PRP-test with Gerbicz error check option instead of LL tests for finding primes, if this error occurs and your Residue at double checks often didn't match. Most errors should be eliminated by PRP testing.



[URL]https://www.mersenne.org/download/whatsnew_294b7.txt[/URL]

p95 not counting PRP exponents toward odds of finding a prime
 

In Prime95 V29.4b8 Win64, I have two systems with multiple workers, which are running a mix of PRP and LL first time test or DC. Both systems seem to be only counting LL tests, not PRP, toward the odds of finding a prime in the listing produced by (Test, Status). Systems running only LL appear normal. A system running only PRP (Prime95 V29.4b7 Win32, or V29.4b8 Win64) does not report any odds of finding a prime.

I had thought that Prime95 would report the combined odds of all PRP and LL tests in the worktodo file finding a prime.

Is this a known issue, or intended behavior?

[QUOTE=kriesel;492071]I had thought that Prime95 would report the combined odds of all PRP and LL tests in the worktodo file finding a prime.[/QUOTE]

I am running all PRP and I get no odds of finding a prime.

[QUOTE=kriesel;492071]
Is this a known issue, or intended behavior?[/QUOTE]

Previously unknown issue, will be fixed.

[QUOTE=Prime95;479687]Build 8 now available for download from [URL]ftp://mersenne.org/gimps[/URL]. Windows and Linux 64-bit only.

Two changes (compare to build 7):

1) Fixes bug where autobench interrupts a torture test.
2) Linked with hwloc 1.11.9. Fixes a crash bug on a new unreleased CPU.[/QUOTE]


I had an unexpected reboot issue with a previous version so I have not ran it in a long time. It would do this while running ECM's. I left the memory settings at their default, for now. My plan is to gradually raise them on a daily basis and see what happens. Hopefully, there will be no issues.

prime95/mprime p-1 exponent limit?
 

From prime95 v29.4's whatsnew.txt:
[QUOTE]New features in Version 25.5 of prime95.exe
6) ECM and P-1 now support B1 and B2 values above 4.29 billion. ECM now
pays attention to the memory settings in the Options/CPU dialog box.

New features in Version 24.12 of prime95.exe
1) For SSE2 machines the larger FFTs have been changed to more effectively
use a wide variety of L2 cache sizes. The previous version was optimized
for a 256KB L2 cache only. Depending on your CPU and FFT size, you could
see an improvement of several percent.
2) As a side "benefit" even larger FFT sizes are now supported. This allows
testing of exponents up to 596 million. Not recommended.[/QUOTE]I did not find in readme.txt, whatsnew.txt, or undoc.txt, an indication of what P-1 factoring's maximum exponent was. Is it the same as for LL or PRP test, 596M?

[QUOTE=kriesel;493227]From prime95 v29.4's whatsnew.txt:
I did not find in readme.txt, whatsnew.txt, or undoc.txt, an indication of what P-1 factoring's maximum exponent was. Is it the same as for LL or PRP test, 596M?[/QUOTE]

Probably the same yes. You can do ECM on F29 which is the same size as a ~537M exponent. But it takes quite some times and you need at least 16 GB RAM for stage2 I think. It might be possible with less, but would take longer time.

[QUOTE=ATH;493229]Probably the same yes. You can do ECM on F29 which is the same size as a ~537M exponent. But it takes quite some times and you need at least 16 GB RAM for stage2 I think. It might be possible with less, but would take longer time.[/QUOTE]
I tried entering a high exponent in prime95's worktodo.txt manually, and got a run time estimate of a year for 544M P-1 on an i3-M370. I've seen in other software that ability to accept and start running an assignment sometimes does not result in successful completion. A cpu-core-year per datapoint is expensive.

An indication from the author what prime95 is intended to handle or known to handle would be good. Or anecdotal info about high values that have been completed. Unfortunately, P-1 shows up in assignments but not in work completed in the work distribution map of primenet.

There's this [URL]https://www.mersenne.org/report_exponent/?exp_lo=595000139&exp_hi=&full=1[/URL] but it doesn't indicate what program was used. [URL]https://www.mersenne.org/report_factoring_effort/?exp_lo=604000000&exp_hi=999999999&bits_lo=81&bits_hi=99&txt=1&tftobits=82[/URL] goes higher but again does not show which software was used.

I did a few ECM curves of F29 on a single core of a Skylake, with B1=50,000 and B2=100 * B1. There was 128 GB of memory on the machine, and for each curve it took about 78 hours to do stage 1 and 40 hours to do stage 2. If 280 curves were completed, this would complete t=25 (that is, the probability of missing a factor under 25 digits would be 1/e, for e=2.7182818...).

I stopped because it turns out that enough exhaustive search on k has been done to eliminate factors smaller than 26 digits. (mentioned [URL="http://mersenneforum.org/showthread.php?p=492270&postcount=25"]here[/URL]). So ECM for F29 only makes sense at the next level of B1=250,000 and B2=100 * B1, but each curve would take quite a lot longer and you'd need to do 640 of them to complete t=30. Maybe a few decades, if done on that single core.

For P−1 to make sense, obviously B1 and B2 would probably need to be quite a bit higher.

[QUOTE=kriesel;493227]I did not find in readme.txt, whatsnew.txt, or undoc.txt, an indication of what P-1 factoring's maximum exponent was. Is it the same as for LL or PRP test, 596M?[/QUOTE]

P-1 is limited by the FFTs, just like LL testing. Thus, 596M is the official maximum. The latest versions support about 920M for FMA3 cpus. This is not heavily advertised as it is painfully slow.

[QUOTE]When looking for probable primes, the following 3 options are available in prime.txt:
SilentVictoryPRP=0 or 1 (default is 1)
OutputPrimes=0 or 1 (default is 1)
OutputComposites=0 or 1 (default is 1)
Setting SilentVictory=0 will cause prime95 to make a continuous noise if a PRP is found.
Setting OutputPrimes=0 will cause prime95 to NOT output probable primes to results.txt.
Setting OutputComposites=0 will cause prime95 to NOT output composite PRP tests to results.txt.[/QUOTE]


I put OutputComposites=0 , but regardless of that fact: Prime95 still output composite to results.txt
Same is if I put OutputPrimes=1 , so Prime95 should in that case only output prp in results.txt
Last, it looks like both settings are related if SilentVictoryPRP is set to 0 or 1

The latest undoc.txt says:

[CODE]When Looking For Probable Primes, The Following 4 Options Are Available In Prime.Txt:
Silentvictoryprp=0 Or 1 (Default Is 1)
Outputprimes=0 Or 1 (Default Is 0)
Outputcomposites=0 Or 1 (Default Is 0)
Outputjson=0 Or 1 (Default Is 1)
Setting Silentvictoryprp=0 Will Cause Prime95 To Make A Continuous Noise If A Prp Is Found.
Setting Outputprimes=1 Will Cause Prime95 To Output A Non-Json Message For Probable Primes To Results.Txt.
Setting Outputcomposites=1 Will Cause Prime95 To Output A Non-Json Message For Composite Prp Tests To Results.Txt.
Setting Outputjson=0 Will Cause Prime95 To Not Output The Json Message For Prp Tests To Results.Txt.
[/CODE]

Is it the JSON text that you are seeing in results.txt? Are you running the latest build?

I think it is not JSON style


3036*140^5007+1 is a probable prime! Wg4: 271E271E,00000000

Trying out PRP-CF but I want prime95 to randomly use all threads despite only setting to run on 3. Machine is a 4C/8T. Basically I would like to see the same behaviour (lower temperatures) when I ran LLR with -3 threads. Is it possible?

Question about throttling
 

I installed Prime95 v29.4 b8 on a Toshiba laptop (2 phyical cores, 2.6GHz, Intel 4xxx family) to sunsome PRPs on small numbers.

I noticed that after the first 10,000 iterations, the ms/iter- value grew of about 60%. I thought it was a heating issue (the laptop is thin and the PSU is quite light).

I decided to give a try to the Throttle=n prameter inside prime.txt file, with n=50, 60 and 30.

The best ms/iter. values re achieved using n=30 (1.7 using 2 cores on a 5,9xx,xxx exponent). The ETA value decreased accordingly. Unfortunately, I also noticed that the wallclock time required to complete 10,000 iterations was not 17 seconds (1.7 ms x 10,000) but about 60 seconds (17*0.30).

am I right in stating that the Throttle=n parameter runs the program for n% of the total time, but the ms/iter and ETA values are computed as there were no slowdown?

Luigi
---

[QUOTE=ET_;495322]
am I right in stating that the Throttle=n parameter runs the program for n% of the total time, but the ms/iter and ETA values are computed as there were no slowdown?
---[/QUOTE]

That sounds correct.

Throttle may be hard on the CPU. It runs flat out for 1.7ms then idles for 3.5ms.

Instead of throttling in Prime95, you can try the Throttlestop program:
[url]https://www.techpowerup.com/download/techpowerup-throttlestop/[/url]

It will prevent your laptop from throttling but then you have to watch the temperature in the beginnning and lower the multiplier until you reach a speed where it does not overheat. But it has nice builtin view of cpu core temperatures.

I'm still using version 6.00 so I do not know if version 8.60 is good.

[QUOTE=Prime95;495335]That sounds correct.

Throttle may be hard on the CPU. It runs flat out for 1.7ms then idles for 3.5ms.[/QUOTE]
I remember seeing prime95's throttling behavior run the cores hard for many seconds and then give them a break, with chip temp changing by more than 10C each time. Now that would be hard on a cpu,all that substantial thermal cycling. Could well have been an earlier release because I saw it on this 8 year old laptop (which still has the original cpu in it).

[QUOTE=kriesel;495376]I remember seeing prime95's throttling behavior run the cores hard for many seconds and then give them a break, with chip temp changing by more than 10C each time. Now that would be hard on a cpu,all that substantial thermal cycling. Could well have been an earlier release because I saw it on this 8 year old laptop (which still has the original cpu in it).[/QUOTE]

Your recollection is likely correct. It has been a long time since I looked at that undoc.txt feature. I'm thinking it should be deprecated in a future release.

[QUOTE=Prime95;495380]Your recollection is likely correct. It has been a long time since I looked at that undoc.txt feature. I'm thinking it should be deprecated in a future release.[/QUOTE]
What I currently see, with Win64 prime95 V29.4b8, running an ecm curve stage 2, in cpuid HWmonitor 1.35, is 82+-1C, much better I think for thermal stress fatigue on components. I hope this throttling feature remains available for the foreseeable future. I have my 8 year old laptop throttled to 30% and it's running 12W of its nominal 25W TDP. It seems to be gradually deteriorating as I recall using 40-45% throttling a couple years ago, and now it occasionally goes to thermal shutdown when some other intensive activity occurs alongside prime95 at 30%.

From undoc.txt in 29.4b8:

[QUOTE]If you want to run the program on several machines this is typically done
by carrying the program and files around on portable media such as a floppy
or USB memory stick. In this case, you need to defeat the program's
automatic detection of hardware changes. To do this, in prime.txt set
FixedHardwareUID=1[/QUOTE]

If I use this on AWS EC2 instance on startup it still says "CPU identity mismatch" and "ComputerGUID=" in local.txt changes and it creates another CPU on my account. That way you get tons of CPUs on your account, a new one every time you loose your session and it automatically starts a new one.

I'm also wondering what is "HardwareGUID=" in prime.txt compared to "ComputerGUID=" in local.txt? There is also a "WindowsGUID=" in prime.txt but it has no value.

[QUOTE=ATH;495447]
If I use this on AWS EC2 instance on startup it still says "CPU identity mismatch" and "ComputerGUID=" in local.txt changes and it creates another CPU on my account. That way you get tons of CPUs on your account, a new one every time you loose your session and it automatically starts a new one.

I'm also wondering what is "HardwareGUID=" in prime.txt compared to "ComputerGUID=" in local.txt? There is also a "WindowsGUID=" in prime.txt but it has no value.[/QUOTE]

I never did figure out a good solution to this.

I just go to the [URL="https://www.mersenne.org/cpus/"]user account CPUs page[/URL] once in a while and and clean out the old missing-in-action red-lined records.

But now I notice that that "Merge checked CPUs" has a "date override" checkbox, that seems to be new. So now instead of deleting those old records, I guess you can just merge them together. That used to be impossible because of date conflicts, it didn't want you to merge machines that were running simultaneously.

"date override" seems to work, so that is an option. But it would be nice if we could avoid the creation of new CPUs.

I am doing some ECM/P-1 work on numbers of the form b^n+-1. Some of these numbers have known small factors.

When I use a large B1 -- most of these small factors are found in the B1 stage and the B2 stage is skipped.

Is this a bug or is there a way to force the program to do the B2 work despite finding a factor in B1?

Thanks.

[QUOTE=Citrix;495713]Is this a bug or is there a way to force the program to do the B2 work despite finding a factor in B1?[/QUOTE]

There is a setting to skip Stage 1 GCD. By default, a GCD is performed after Stage 1, and if it finds a factor, then why should it continue?

You can add the known factors in the worktodo line, then they will not be found again:

Pminus1=k,b,n,c,B1,B2[,"comma-separated-list-of-known-factors"]
ECM2=k,b,n,c,B1,B2,curves_to_run[,"comma-separated-list-of-known-factors"]


Here is an example of ECM on F12 with the known factors included with B1=800M:
ECM2=1,2,4096,1,800000000,80000000000,1,"114689,26017793,63766529,190274191361,1256132134125569,568630647535356955169033410940867804839360742060818433"

[QUOTE=axn;495718]There is a setting to skip Stage 1 GCD. [/QUOTE]

How do I use this setting?

Thank you ATH, your option should also work.

[QUOTE=axn;495718]There is a setting to skip Stage 1 GCD. By default, a GCD is performed after Stage 1, and if it finds a factor, then why should it continue?[/QUOTE]

Some stage 2 setup will do modular inverses. If these find a factor, you have the same problem where prime95 will stop.

[QUOTE=Prime95;495723]Some stage 2 setup will do modular inverses. If these find a factor, you have the same problem where prime95 will stop.[/QUOTE]

Is that only for ECM or for P-1 as well (I don't remember P-1 stage 2 setup requiring modular inverse)?

[QUOTE=axn;495726]Is that only for ECM or for P-1 as well (I don't remember P-1 stage 2 setup requiring modular inverse)?[/QUOTE]

I think that is ECM only.

There's a bug in the PRP code when using a non-standard repunit base (i.e., other than Mersenne b = 2) and a non-standard PRP base, which might possibly indicate a wider problem.

For instance, doing PRP on (3^p − 1) / (3 − 1), which is the base-3 repunit counterpart to the base-2 repunit (2^p − 1) / (2 − 1) aka Mersenne number.

Here the known probable primes are (from [URL="https://oeis.org/A028491"]OEIS sequence A028491[/URL]) 3, 7, 13, 71, 103, 541, 1091, 1367, 1627, 4177, 9011, 9551, 36913, 43063, 49681, 57917, 483611, 877843

This can't use the standard PRP base = 3 because the repunit base is already 3. So, using PRP base 5 and residue type 5, we have the following lines in worktodo.txt:

[CODE]
PRP=1,3,p,-1,99,0,5,5,"2"
[/CODE]

The residues for composite numbers match what they should be, but for the exponents that produce primes, the upper 32-bit half of the 64-bit residue is sometimes wrong:

[CODE]
3 0000000000000001
7 0000000000000001
13 0000000000000001
71 0000000000000001
103 0000000000000001
541 40B03E9E00000001
1091 40ED526E00000001
1367 40ED600100000001
1627 4120480C00000001
4177 4141263900000001
9011 410B27E100000001
9551 C126793A00000001
[/CODE]

Also, it's marking them all as composite rather than as probable primes, even for very small exponents, for example:

[CODE]
{[B]"status":"C"[/B], "k":1, "b":3, "n":13, "c":-1, "known-factors":"2", "worktype":"PRP-5", "res64":"0000000000000001", "residue-type":5, "fft-length":32, "error-code":"00000000", "security-code":"001A001A", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, "timestamp":"2018-09-12 07:40:57", ...
[/CODE]

This is worrisome because if there's a bug that partially overwrites the residue under some circumstances, then perhaps it might possibly affect the Mersenne PRP tests as well.

In case it's useful, I'm attaching a Python script that calculates PRP residues (slowly, for small exponents), which can be used to compare the residues from mprime. For the above values (base-3 repunit with base-5 PRP and 64-bit residues) it can be invoked with:

[CODE]
python ./grpr_py.txt -b 3 -a 5 -t 64 PRIMES_10k.txt
[/CODE]

I can verify that if the final result is less than 33 bits long, then the top 32-bits of a PRP residue are trash.

I've not looked at why it is reporting composite. I suspect type-1 PRP test would report as PRP.

Seems to work on type 1+2 for known repunit primes/PRPs for base 3,5,6,7,10 for p<50000.

It also works for type 3+4 but since they are not available for b!=2, it must be switching to type 1 most likely without informing?

[QUOTE=Prime95;495974]I can verify that if the final result is less than 33 bits long, then the top 32-bits of a PRP residue are trash.

I've not looked at why it is reporting composite. I suspect type-1 PRP test would report as PRP.[/QUOTE]

Yes, the type-1 tests with PRP base a=5 for b=3 do report status=P correctly for the exponents 3, 7, 13, 71, 103, 541, 1091...

But getting back to the type-5 residues, it seems to be doing the calculation differently if b is not 2:

Let:
numer = b[SUP]p[/SUP] − 1
denom = b − 1
repunit = numer / denom

In the case of Mersenne numbers, b = 2 so numer = 2[SUP]p[/SUP] − 1 and denom = 1
In the case of Wagstaff numbers, b = −2 so numer = (2[SUP]p[/SUP] + 1) and denom = 3
If b = 3 then numer = (3[SUP]p[/SUP] − 1) and denom = 2

In the case of Wagstaff b = −2, it is calculating the type-5 residue as:
PRP res = powmod(a, numer − 1, numer)

But for other non-Mersenne bases b != 2, it is calculating the type-5 residue as:
PRP res = powmod(a, repunit − 1, numer)

I don't know if this difference is intentional.

(and obviously for Mersenne b = 2, denom = 1 so there is no difference between the two forms, and I think it's considered a type-1 residue in any case)

So for b != 2 and b != −2, for the composite residues it's doing the calculation correctly but perhaps it's doing the wrong calculation. I'm not sure if the calculation it's actually doing is still compatible with the Gerbicz rapid cofactor-compositeness test.

Whereas for the prime residues, it should be calculating exactly 1, but something goes wrong. I took a look at the 2048-bit residues. For p = 3, 7, 13, 71, 103 the 2048-bit residue is exactly 1, but it gets reported as composite, so maybe some of the bits beyond 2048 are nonzero. And for p = 541, 1091, ... only bits 0 through 31 are exactly 00000001 and all the bits from 32 to 2047 are filled with seemingly random garble.

[QUOTE=GP2;495988]And for p = 541, 1091, ... only bits 0 through 31 are exactly 00000001 and all the bits from 32 to 2047 are filled with seemingly random garble.[/QUOTE]

Sorry, obviously I meant to say that the bits from 32 to maximum are filled with random garble, obviously p = 541 doesn't have 2048 bits of residue.


Anyway, for b != 2, the Type-5 residues as currently being calculated by mprime/Prime95 don't have the basic property of being invariant as the number of factors changes.

For example, for b=3, the repunits are ( 3[SUP]p[/SUP] − 1 ) / 2, and we have to use the PRP base 5 instead of 3.

For residue type 1 we have:

[CODE]
PRP=1,3,2131,-1,99,0,5,1,"2"
PRP=1,3,2131,-1,99,0,5,1,"2,459589675789"
PRP=1,3,2131,-1,99,0,5,1,"2,459589675789,147045472166651"
[/CODE]

and the output is:

[CODE]
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2", "worktype":"PRP-5", [B]"res64":"8E75A8D17A4BE62C"[/B], "residue-type":1, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ... }
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789", "worktype":"PRP-5", [B]"res64":"362984CF537671B3"[/B], "residue-type":1, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
{[B]"status":"P"[/B], "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789,147045472166651", "worktype":"PRP-5", "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
[/CODE]

while for residue type 5 we have:

[CODE]
PRP=1,3,2131,-1,99,0,5,5,"2"
PRP=1,3,2131,-1,99,0,5,5,"2,459589675789"
PRP=1,3,2131,-1,99,0,5,5,"2,459589675789,147045472166651"
[/CODE]

and the output is:

[CODE]
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2", "worktype":"PRP-5", [B]"res64":"C6369199A87B8799"[/B], "residue-type":5, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789", "worktype":"PRP-5", [B]"res64":"DD08BBFDEC5278FB"[/B], "residue-type":5, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
{[B]"status":"C"[/B], "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789,147045472166651", "worktype":"PRP-5", [B]"res64":"57CA39292A83D0FD"[/B], "residue-type":5, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
[/CODE]

and for both type-1 and type-5, the residues, as calculated by mprime, change as we add known factors to the factor string.


And additionally, type-5 fails to recognize that the final cofactor is a probable prime (actually [URL="http://factordb.com/index.php?id=1100000000094644030"]a certified prime[/URL]).

[QUOTE=GP2;496024]
and for both type-1 and type-5, the residues, as calculated by mprime, change as we add known factors to the factor string.

[/QUOTE]

At least those type 1 results are good, for example:
[CODE]
(09:56) gp > N=(3^2131-1)/2/459589675789;
(09:56) gp > lift(Mod(5,N)^(N-1))%(2^64)
%2 = 3902796578086613427
(09:56) gp >
[/CODE]

[QUOTE=R. Gerbicz;496055]At least those type 1 results are good, for example:
[CODE]
(09:56) gp > N=(3^2131-1)/2/459589675789;
(09:56) gp > lift(Mod(5,N)^(N-1))%(2^64)
%2 = 3902796578086613427
(09:56) gp >
[/CODE][/QUOTE]

After I looked at it again and fixed my code, it seems that for repunit base b=3, it is sufficient just to use type-1 residues with PRP base 2.

I was able to use your cofactor-compositeness method and calculated modular inverse to "rediscover" the PRP cofactor exponents p = 2113, 2131, 2141, 2203, 2213, 2417, 2531, 2539, 2699, 4967, 6961, 7577, 8741, 17477, 24697, 26849, 58403.

That was using the limited selection of factors of 3^p − 1 available on FactorDB: only factored to very limited bit depth and only up to p = 100k. Maybe mfaktc can be adapted to find more factors of this form.

I'm not sure about negative bases though. I know that for b = −2 Wagstaff numbers a type-5 residue is calculated, it seems to be a special case. Maybe there might still be an issue for negative bases other than b = −2, especially if the denominator (b + 1) is an even number. I'll look at that later. But I guess for positive bases the type-5 issue doesn't matter.

[QUOTE=GP2;496091]
I'm not sure about negative bases though. I know that for b = −2 Wagstaff numbers a type-5 residue is calculated, it seems to be a special case. Maybe there might still be an issue for negative bases other than b = −2, especially if the denominator (b + 1) is an even number. I'll look at that later. But I guess for positive bases the type-5 issue doesn't matter.[/QUOTE]

Doing (say) a Fermat prp test for base=-b is equivalent to a test to base=b. The generalization of this is that the good bases form a group in Z_N; this is the reason why we use (distinct small) prime bases in general.

A quick question about [I]Prime95[/I]. From [I]undoc.txt[/I]:

[QUOTE]You can control the maximum prime.log file size. The default is 2MB. Add
this line to prime.txt to change the default:
MaxLogFileSize=n[/QUOTE]How do you specify a size for this? Is it in "K" or "M" or some other way?

[QUOTE=storm5510;496685]A quick question about [I]Prime95[/I]. From [I]undoc.txt[/I]:

How do you specify a size for this? Is it in "K" or "M" or some other way?[/QUOTE]

I think it is in bytes.