**Server Support****TF**

Up to 1G exponent at mersenne.org; 1G to 10G at mersenne.ca

**P-1**

Up to 1G exponent at mersenne.org

**LL**

Up to 1G exponent at mersenne.org

**PRP**

Up to 1G exponent at mersenne.org, although note, currently the server is limited by its SSE2 instruction set to PRP proof file processing up to ~595.7M automatically

**Software availability****TF**

Mfaktx are capable of up to 2^{32}-1 (largest prime exponent 4,294,967,291). Mfakto for AMD GPUs or Intel IGPs or AMD IGPs, Mfaktc for CUDA (NVIDIA) GPUs.

**P-1**

**Mlucas** current release does not support P-1. The capability is being added.

**CUDAPm1** is theoretically capable of up to 2^{31}-1 (largest prime exponent 2,147,483,647) but in practice may reach to ~100Mdigit on a reasonably modern NVIDIA GPU.

**Mprime/prime95** are capable of up to varying exponents depending on CPU type, with maximum 64K fft length on AVX512 allowing ~1169M.

Various versions of **Gpuowl** support P-1 either standalone or as part of a PRP run (but not both). The fft lengths supported are one determinant of the maximum exponent. The maximum exponent for P-1 may be less than for PRP, depending at least upon bounds and available GPU or system memory, and a bit more requirement for carry handling reducing the available bits/word on a given fft. No gpuowl version to date supports gigadigit exponent P-1. I have performed complete P-1 runs to mersenne.ca recommended GPU72 bounds on local Radeon VII and Colab provided P100 GPUs up to 1Gbit. Current versions of gpuowl support fft lengths consistent with P-1 to about exponent 2^{31}-1. Most P-1 implementations are without offset, Jacobi symbol check, or GEC. GpuOwl V7.x supports both some GEC and Jacobi symbol checking during P-1 computations combined with PRP.

**PRP**

**ONLY PRP with GEC & Proof should be considered for new first primality tests.**

**Mprime/prime95** are capable of up to varying exponents depending on CPU type, with maximum 64K fft length on AVX512 allowing up to ~1169M.

**Gpuowl **in relatively current and efficient versions is capable of 120M fft lengths, nominally capable of 2172.36M per its help output.

Gpuowl around V6.5-84 was capable of PRP on gigadigit exponents and a bit more, 3339.40M indicated in the help output.

**Mlucas** is capable with fft lengths up to 256M of up to 2^{32}-1 (largest prime exponent 4,294,967,291). V20 will support larger, including 512M fft lengths for F33 and so presumably up to ~M8,589,934,583 (which has a known factor). PRP proof capability is also being added.

**LL**

**LL should be considered as for primality verification or reliability research purposes only, not suitable for ordinary first tests! Even its use in LLDC is questionable.**

**Mprime/prime95** are capable of up to varying exponents depending on cpu type, with maximum 64M fft length on AVX512 allowing ~1169M.

**CUDALucas** is nominally capable of up to 256M fft (for recent CUDA versions), which would be sufficient for ~2^{32}-1. However, its exponent variable is signed 32 bit, 2^{31}-1 (largest prime exponent 2,147,483,647), capping exponent for fft lengths 128M and above. In practice it is limited further, to ~1.43Gbits, determined empirically, as shown below.

**Gpuowl **in relatively current and efficient versions is capable of 120M fft lengths, though there may be issues in its upper reaches also. Nominally that is capable of 2172.36M.

Gpuowl around V6.5-84 was nominally capable of gigadigit exponents but did not include LL then.

**Mlucas** is capable with fft lengths up to 256M of up to 2^{32}-1 (largest prime exponent 4,294,967,291). V20 will support larger, including 512M fft lengths for F33 and so presumably up to ~M8,589,934,583 (which has a known factor). Mlucas does not yet implement the Jacobi symbol check for LL testing.

**Memory requirements**There are several requirements to consider. Disk space, system ram, and sometimes GPU ram; also how much data may be transferred to and from the PrimeNet server in the case of PRP proof and certification.

TF: minor

P-1: large

Gpuowl typically requires at least 16 or 24 buffers available on the GPU for P-1 stage 2. This limits the maximum exponent according to GPU memory capacity. On 16GB GPUs, up to 1G exponents can be run in v6.11-380, and at least slightly higher. (1,000,000,007 ran successfully to completion of both stages on a Radeon VII.)

PRP:

GPU-Z indicates usage of 2.7 GB GPU ram in Gpuowl v6.11-318 for exponent ~2^{31}.

Interim save files will be at least the binary packed size of the exponent, plus some words for housekeeping, such as file format, exponent, iteration, etc. Most applications save one or two residues in a save file. Mprime / prime95 for some cases will store up to 3. So a rough bound for prime95 save files is 3/8 p bytes each.

The number of save files saved is controlled by each program's settings.

For temporaries stored on disk for proof generation, their total size and timing depends on the application, exponent, and proof power.

Mprime / prime95 pre-allocates space sufficient for all the temporaries. Gpuowl adds individual temporaries files as the PRP computation progresses.

LL:

Storage requirements are similar to PRP without proof.

**Run time scaling**Run time scaling for some specific hardware and software combinations can be found in the relevant software-specific reference threads.

TF: exponential in bit level, inversely proportional to exponent for a given bit level. The overall effect since recommended bit level increases with exponent is run time increases with exponent. Large exponents can require weeks of TF on a fast GPU to complete recommended levels.

P-1: to optimal bounds, about 1/30 of primality testing time.

Primality testing: scales as approx exponent^{2.1}.

**Hardware lifetime**Run times of large exponents may exceed the probable hardware useful life, or the user's remaining life expectancy. A good backup regimen and transfer to replacement hardware is a workaround, if the user has enough patience and human life expectancy remaining. Very long undertakings may also need a succession plan.

**Software & Hardware combination reliability****Overall experience**

Madpoo has checked error rate of primality tests on occasion. Most of the data points are at much smaller exponent than the current wavefronts. Run time was probably substantial at the time they were performed. Observed error rate was about 4% per exponent, 2% per test. These results date from before introduction to GIMPS testing of the LL Jacobi symbol check or PRP or GEC. (See https://mersenneforum.org/showpost.p...1&postcount=67)

**100M exponent experience**

For the period October 1 2020 to March 26 2021, the observed rate of LL final residue error per test for exponents between 97M and 103M was ~0.94%. Presumably most of these were performed with mprime / prime95 with the Jacobi check, and some were with ECC system ram. (See first attachment.)

Extrapolating to approximately triple the exponent, ten times the run time, projects ~10% error rate at 100Mdigit; to ten times the exponent, 126 times the run time, projects a very high error rate for single-run gigabit exponents, ~30% chance of correct result, 70% chance of error in the result. Extrapolating further to gigadigit, 12.44 times the runtime of a gigabit test, near certainty of error, ~0.37 ppm chance of correct result.

Longer term average error rate was found to be higher, at ~2.5% for exponents 97M-103M. This is probably reflective both of runs without Jacobi symbol check and longer run times on slower hardware in previous years. (See second attachment.)

More detail on observed error rates can be found at https://www.mersenneforum.org/showpo...40&postcount=4 and its links.

**Limited data on 100Mdigit**

There are very few verified exponents from which to assess 100 Mdigit LL test error rate. The available data indicates about 21.% error rate. Many of these were done long ago, probably with long run times and without the benefit of any Jacobi check. (See third attachment.)

**Higher**

There's very little data for above the 100Mdigit region. Most over 350M were done as paired LL runs with regular interim residue comparison, or as PRP with GEC. Extrapolations to gigabit / 300M digit indicate paired runs with frequent interim res64 or other, new error checks or approaches will be required for LL testing. (See fourth attachment.)

CUDALucas is Lucas-Lehmer test capable only, not PRP. It lacks Jacobi symbol check. The GEC that is so useful in keeping PRP runs reliable is not applicable to the LL residue sequence, so not applicable to CUDALucas. It is also slower than recent Gpuowl (V6.11-3xx, v7.x-y) on the same hardware and assignment. Avoid CUDALucas, use Gpuowl whenever possible.

**100Mdigit experiments**
Obtaining matching interim residues of 100Mdigit exponents is usually straightforward on available software and adequate reliability hardware. Matching interim residues were produced with independent runs on the first tries, among Mlucas and Gpuowl for LL, and Gpuowl for PRP. (See

https://www.mersenneforum.org/editpo...&postid=546384 for details)

**~gigabit** or

**300Mdigit** **experiments**
Obtaining matching interim residues of 300Mdigit exponents involved 4 attempts to get two matching. Details follow; results are summarized at the above link.

interim residues (mostly unverified, except for

**green**)

CUDALucas v2.06 on gtx1080ti (LL, no Jacobi check, unverified; not recommended at 1.4 years estimated duration on a GTX1080Ti)

999999937 301,029,977 decimal digits

Code:

| Jan 09 04:48:51 | M999999937 **10000 0x567ad47461d3bb5f ** | 57344K 0.21875 41.1682 41.16s | 473:21:41:27 0.00% |
| Jan 20 08:14:38 | M999999937 100000 ** 0xe776f4a0dcd3491d** | 57344K 0.18750 44.3713 44.37s | 506:19:41:57 0.01% |
| Jan 20 19:26:39 | M999999937 1000000 0x141a108c13a86d5a | 57344K 0.18750 45.3946 45.39s | 516:19:59:55 0.10% |
| Jan 23 07:03:54 | M999999937 5000000 0x0811f10855dab84c | 57344K 0.20313 44.9825 44.98s | 516:10:56:38 0.50% |

CUDALucas v2.06 on gtx1080 (LL, no Jacobi check, unverified; not recommended at 1.85 years estimated duration on a GTX1080

Code:

| Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done |
| Mar 27 13:24:34 | M999999937 10000 **0xd0ba62caab74a325** | 57344K 0.20313 58.3992 224.72s | 671:06:41:49 0.00% |
| Mar 27 13:34:21 | M999999937 20000 0x3b0de44a71284153 | 57344K 0.20313 58.7176 587.17s | 675:10:19:38 0.00% |
| Mar 27 13:44:08 | M999999937 30000 0xee988cb77112ea03 | 57344K 0.20313 58.7149 587.14s | 676:19:10:58 0.00% |
| Mar 27 13:53:55 | M999999937 40000 0x906263cb2b36ac4c | 57344K 0.20313 58.7086 587.08s | 677:11:05:19 0.00% |
| Mar 27 14:03:43 | M999999937 50000 0x454a88b55988ce1e | 57344K 0.21094 58.7162 587.16s | 677:20:59:32 0.00% |

(deleted this bad run's set of interim residue files)
Any residues produced after a known-bad residue (**red** or **purple** here) will also be bad. The grayed lines are preserved since they show iteration speed variation.

**Gpuowl** (which has the Jacobi check for LL) on RX480, not recommended at 1.56 years or more depending on gpuowl version; GTX1080 similar; Radeon VII marginally feasible at ~6 months

Code:

2019-02-08 17:34:48 gpuowl v6.2-e2ffe65
2019-02-08 17:34:48 condorella/rx480 -user kriesel -cpu condorella/rx480 -device 0 -fft +0
2019-02-08 17:34:48 condorella/rx480 999999937 FFT 73728K: Width 256x8, Height 256x8, Middle 9; 13.25 bits/word
2019-02-08 17:34:48 condorella/rx480 using long carry kernels
2019-02-08 17:34:54 condorella/rx480 OpenCL compilation in 5333 ms, with "-DEXP=999999937u -DWIDTH=2048u -DSMALL_HEIGHT=2048u -DMIDDLE=9u -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-02-08 17:35:06 condorella/rx480 999999937.owl not found, starting from the beginning.
2019-02-08 17:37:08 condorella/rx480 999999937 OK 800 0.00%; 71.64 ms/sq; ETA 829d 05:22; c3c8e02da339fdfa (check 31.90s)
2019-02-08 17:48:10 condorella/rx480 999999937 10000 0.00%; 72.02 ms/sq; ETA 833d 14:01; **a30a0c45e9fb828c**
2019-02-08 21:16:26 condorella/rx480 999999937 100000 0.01%; 74.38 ms/sq; ETA 860d 18:51; 3efc806b68d92b86

gpuowl v6.10-9-g54cba1d on RX480 continuation from 102000 to 495600

2021-03-15 23:16:33 999999937 FFT 57344K: Width 256x8, Height 256x8, Middle 7; 17.03 bits/word
gpuowl v6.11-380-g79ea0cc on RX480 continuation

Code:

2021-03-16 06:23:01 condorella/rx480 999999937 FFT: 56M 4K:14:512 (17.03 bpw)
2021-03-16 06:23:01 condorella/rx480 Expected maximum carry32: 833C0000
2021-03-16 06:51:54 condorella/rx480 999999937 OK 600000 0.06%; 49222 us/it; ETA 569d 08:39; c974a7f641226218 (check 21.93s)
2021-03-16 09:36:25 condorella/rx480 999999937 OK 800000 0.08%; 49242 us/it; ETA 569d 11:23; 321dd77853313c0c (check 22.04s)
2021-03-16 12:20:54 condorella/rx480 999999937 OK 1000000 0.10%; 49236 us/it; ETA 569d 07:00; e1b53ccf581f928b (check 22.08s)

(deleted this bad run's set of interim residue files)

gpuowl v6.11-380-g79ea0cc independent run from start on gtx 1080

Code:

2021-03-27 14:28:07 gpuowl v6.11-380-g79ea0cc
2021-03-27 14:28:07 config: -device 1 -user kriesel -cpu asr3/gtx1080 -maxAlloc 6500 -proof 9 -cleanup -yield -use NO_ASM
2021-03-27 14:28:07 device 1, unique id ''
2021-03-27 14:28:07 asr3/gtx1080 999999937 FFT: 56M 4K:14:512 (17.03 bpw)
2021-03-27 14:28:07 asr3/gtx1080 Expected maximum carry32: 833C0000
2021-03-27 14:28:16 asr3/gtx1080 OpenCL args "-DEXP=999999937u -DWIDTH=4096u -DSMALL_HEIGHT=512u -DMIDDLE=14u -DPM1=0 -DCARRY64=1 -DWEIGHT_STEP_MINUS_1=0xf.57fb440c6997p-4 -DIWEIGHT_STEP_MINUS_1=-0xf.aa3b4ca84faap-5 -DNO_ASM=1 -cl-unsafe-math-optimizations -cl-std=CL2.0 -cl-finite-math-only "
2021-03-27 14:28:22 asr3/gtx1080
2021-03-27 14:28:22 asr3/gtx1080 OpenCL compilation in 6.10 s
2021-03-27 14:28:24 asr3/gtx1080 999999937 LL 0 loaded: 0000000000000004
2021-03-27 14:29:14 asr3/gtx1080 Stopping, please wait..
2021-03-27 14:29:16 asr3/gtx1080 999999937 LL 1000 0.00%; 52191 us/it; ETA 604d 01:29; **ddadfed64e080856**
(Jacobi check on exit passed; continuing:)
2021-03-27 14:55:18 asr3/gtx1080 999999937 LL 10000 0.00%; 50442 us/it; ETA 583d 19:32; **567ad47461d3bb5f**
2021-03-27 15:03:46 asr3/gtx1080 999999937 LL 20000 0.00%; 50782 us/it; ETA 587d 17:50; 78a2f270a1bba92d
2021-03-27 15:12:14 asr3/gtx1080 999999937 LL 30000 0.00%; 50794 us/it; ETA 587d 21:05; d79b942904525426
2021-03-27 15:20:42 asr3/gtx1080 999999937 LL 40000 0.00%; 50823 us/it; ETA 588d 05:02; 650ca8c106ac7d12
2021-03-27 15:29:11 asr3/gtx1080 999999937 LL 50000 0.01%; 50869 us/it; ETA 588d 17:34; 98420630c9a4b877
2021-03-27 15:37:39 asr3/gtx1080 999999937 LL 60000 0.01%; 50850 us/it; ETA 588d 12:03; adb31fa7cf23b0ba
2021-03-27 15:46:08 asr3/gtx1080 999999937 LL 70000 0.01%; 50847 us/it; ETA 588d 11:13; 20b88580b0d5c8a5
2021-03-27 15:54:38 asr3/gtx1080 999999937 LL 80000 0.01%; 51002 us/it; ETA 590d 06:05; 2b4ab3e44fcbdc84
2021-03-27 16:03:07 asr3/gtx1080 999999937 LL 90000 0.01%; 50957 us/it; ETA 589d 17:20; b9c6eeca4e553904
2021-03-27 16:11:37 asr3/gtx1080 999999937 LL 100000 0.01%; 50972 us/it; ETA 589d 21:24; **e776f4a0dcd3491d**

CUDALucas V2.06beta on V100 (LL, no Jacobi check, unverified, ~6 months; interim residue extracted by ramgeis from an interim save file using a perl program provided by Kriesel) This run was preceded and followed by successful LL DC runs. However, it was not a paired run with interim residues cross-checked, so its reliability over the long run time is uncertain.

999999937 Iteration 110,000,000 Residue64 0x87ded9d3ab3e7f38

See also

https://mersenneforum.org/showthread...859#post495859
The PRP equivalent is feasible marginally with Gpuowl on a Radeon VII, at ~0.5 years to complete; LL in Gpuowl on a Radeon VII is also possible but not recommended since it's only protected by an occasional Jacobi check's ~50% chance of detection of an error. Such long runs are likely to go wrong with undetected errors.

Gpuowl v6.2-e2ffe65 PRP on RX480:

Code:

2019-02-08 17:48:10 condorella/rx480 999999937 10000 0.00%; 72.02 ms/sq; ETA 833d 14:01; a30a0c45e9fb828c
2019-02-08 21:16:26 condorella/rx480 999999937 100000 0.01%; 74.38 ms/sq; ETA 860d 18:51; 3efc806b68d92b86

continuation on gpuowl v6.11-380-g79ea0cc on RX480, quite a speed improvement, 1.51X over v6.2, but still not recommended at ~1.56 years on an RX480:

Code:

2021-03-16 12:20:54 condorella/rx480 999999937 OK 1000000 0.10%; 49236 us/it; ETA 569d 07:00; e1b53ccf581f928b (check 22.08s)

**1.25Gbit **experiment

CUDALucas on GTX1080 wrote a save file and stopped upon request.

Code:

Using threads: square 512, splice 64.
Starting M1250000033 fft length = 73728K
SIGINT caught, writing checkpoint. Estimated time spent so far: 12:18

A resumption produced

Code:

| Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done |
| Mar 28 13:21:04 | M1250000033 10000 0xf40e592716cd5c7a | 73728K 0.12500 75.3094 11.14s | 1084:17:26:53 0.00% |

This residue is unverified and conflicts with the one produced by gpuowl v6.11-380 on a Radeon VII gpu:

Code:

2021-03-30 18:45:38 gpuowl v6.11-380-g79ea0cc
2021-03-30 18:45:38 config: -user kriesel -cpu asr2/radeonvii4 -d 4 -use NO_ASM -maxAlloc 15000 -cleanup -block 1000 -log 10000
2021-03-30 18:45:38 device 4, unique id ''
2021-03-30 18:45:38 asr2/radeonvii4 1250000033 FFT: 72M 4K:9:1K (16.56 bpw)
2021-03-30 18:45:38 asr2/radeonvii4 Expected maximum carry32: 6CC80000
2021-03-30 18:45:49 asr2/radeonvii4 OpenCL args "-DEXP=1250000033u -DWIDTH=4096u -DSMALL_HEIGHT=1024u -DMIDDLE=9u -DPM1=0 -DAMDGPU=1 -DWEIGHT_STEP_MINUS_1=0xb.819f9530b86cp-5 -DIWEIGHT_STEP_MINUS_1=-0x8.76945b26097f8p-5 -DNO_ASM=1 -cl-unsafe-math-optimizations -cl-std=CL2.0 -cl-finite-math-only "
2021-03-30 18:45:54 asr2/radeonvii4 OpenCL compilation in 4.79 s
2021-03-30 18:46:00 asr2/radeonvii4 1250000033 LL 0 loaded: 0000000000000004
2021-03-30 18:48:54 asr2/radeonvii4 1250000033 LL 10000 0.00%; 17459 us/it; ETA 252d 13:58; 5a7f1ee464e7c654
2021-03-30 18:51:48 asr2/radeonvii4 1250000033 LL 20000 0.00%; 17428 us/it; ETA 252d 03:27; 1bdc8fcb27f794f5
2021-03-30 18:52:26 asr2/radeonvii4 Stopping, please wait..
2021-03-30 18:52:29 asr2/radeonvii4 1250000033 LL 22000 0.00%; 20088 us/it; ETA 290d 14:53; b2fc2c1ace615898
2021-03-30 18:52:29 asr2/radeonvii4 waiting for the Jacobi check to finish..
2021-03-30 19:11:16 asr2/radeonvii4 1250000033 OK 22000 (jacobi == -1)

**1.4xGbit** experiments

These were performed after the 2Gbit, 1.5Gbit, and 1.25Gbit experiments, to determine the approximate transition point for CUDALucas. The following are in exponent order, not chronological order.

**1.40G**
Code:

Using threads: square 1024, splice 32.
Starting M1400000197 fft length = 81920K
| Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done |
| Mar 27 09:32:44 | M1400000197 10000 0x3064425057775e29 | 81920K 0.17188 85.1755 851.75s | 1380:03:35:56 0.00% |
exit at Sat 03/27/2021 9:47:05.96

**1.43G** is about the highest that would run in CUDALucas on the GTX1080 long enough to produce any printed interim residues; 1.45Gbit and higher failed early.

Code:

Starting M1430000027 fft length = 81920K
| Date Time | Test Num Iter Residue | FFT Error ms/It Time | ETA Done |
| Mar 27 11:28:40 | M1430000027 10000 0xa58244f8b0e73cde | 81920K 0.26563 85.7222 857.22s | 1418:18:31:51 0.00% |
| Mar 27 11:42:59 | M1430000027 20000 0x210de9223d1c0ca0 | 81920K 0.29688 85.9697 859.69s | 1420:19:27:07 0.00% |
| Mar 27 11:57:19 | M1430000027 30000 0xf17cde78a6256ad9 | 81920K 0.28125 85.9585 859.58s | 1421:10:07:19 0.00% |
| Mar 27 12:11:38 | M1430000027 40000 0x6863e2b56e6e5d89 | 81920K 0.28125 85.9554 859.55s | 1421:17:01:24 0.00% |
exit at Sat 03/27/2021 12:26:00.77

Compare the above 10000 iter residue to gpuowl v6.11-380's Jacobi checked output

**19b5110e4fd08ef6**
At

**1.44G** CUDALucas struggled and crashed

Code:

Using threads: square 32, splice 32.
Starting M1440000083 fft length = 82944K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 82944K.
Restarting from last checkpoint to see if the error is repeatable.
Using threads: square 32, splice 32.
Starting M1440000083 fft length = 82944K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 82944K.
The error persists.
Trying a larger fft until the next checkpoint.
Using threads: square 32, splice 128.
Starting M1440000083 fft length = 84672K

**1.45G** just crashed CUDALucas.

Code:

Using threads: square 32, splice 32.
Starting M1450000043 fft length = 82944K

The 100M steps in test exponent sometimes correspond to different expected fft lengths.

**1.5Gbit** experiments

interim residues

gpuowl v4.6 PRP on RX480 (not recommended, at estimated 7.8 years to completion; also moot since it has a known small factor) B1 bounds 0, so presumably base = 3.

2018-11-01 16:35:37 condorella-rx480 10000/

1500000041 [ 0.00%], 164.51 ms/it [163.50, 174.58]; ETA

**2856**d 01:42;

CUDALucas v2.06 fails on

1,500,000,043 with an error similar to that for 2Gbit (see below).

Code:

Using threads: square 512, splice 128.
Starting M1500000043 fft length = 86400K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 86400K.
Something is wrong! Quitting.

**2Gbit** experiments

https://www.mersenne.ca/exponent/2147483563 is theoretically just within range of CUDALucas. It would need a lot of TF and P-1 before a serious attempt at LL were worthwhile. Estimated time on a GTX1080 is several years to completion, and little or no chance of correct completion without the Jacobi check or better.

In initial attempts to obtain LL timing on a GTX 1080, CUDALucas halted repeatedly before producing any timing data. A few more attempts were made after tuning the application for the GPU on the system where it's currently installed. It initially selects a properly sized fft length, decides that's too large, goes to one too small, and has excessive round-off error, terminating, even if a proper fft length is specified on the command line.

Code:

The fft length 131072K is too large for exponent 2147483563, decreasing to 116640K
Using threads: square 1024, splice 64.
Starting M2147483563 fft length = 116640K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 116640K.
Something is wrong! Quitting.

The relevant fft lengths and benchmark timings are

Code:

Device GeForce GTX 1080
Compatibility 6.1
clockRate (MHz) 1797
memClockRate (MHz) 5005
fft max exp ms/iter
76832 1335757897 83.2664
81920 1422251777 83.9003
82944 1439645131 84.9825
84672 1468986017 91.3988
86400 1498314007 94.8596
93312 1615502269 96.7309
96768 1674025489 99.3981
98304 1700021251 103.3561
100352 1734668777 105.2496
102400 1769301077 110.3034
104976 1812840839 112.3060
110592 1907684153 113.6384
114688 1976791967 117.1181
115200 1985426669 124.0529
116640 2009707367 131.0044
131072 2147483647 131.6075

The issue was reproducible on

2,000,000,099 and some lower values.

Code:

Using threads: square 1024, splice 64.
Starting M2000000099 fft length = 115200K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 115200K.
Restarting from last checkpoint to see if the error is repeatable.
Using threads: square 1024, splice 64.
Starting M2000000099 fft length = 115200K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 115200K.
The error persists.
Trying a larger fft until the next checkpoint.
Using threads: square 1024, splice 64.
Starting M2000000099 fft length = 116640K
Round off error at iteration = 100, err = 0.5 > 0.35, fft = 116640K.
Something is wrong! Quitting.

P-1 stage 1 appears possible on gpuowl v6.11-380, at over 6 days on a Radeon VII:

Code:

2021-03-26 13:57:40 asr2/radeonvii4 2147483563 P1 B1=11000000, B2=600000000; 15869712 bits; starting at 0
2021-03-26 14:02:48 asr2/radeonvii4 saved
2021-03-26 14:03:21 asr2/radeonvii4 2147483563 P1 10000 0.06%; 34113 us/it; ETA 6d 06:17; d78cbf554970d8c1

P-1 stage 2 is unlikely to work, since gpu ram of 16 GB is barely adequate (-maxalloc 15000) for exponents near 1G.

https://www.mersenne.ca/exponent/2147483743 would need a lot of TF and P-1 first, before a serious attempt at PRP testing was made. This is far beyond the capability of CUDAPm1, and requires a 16GB GPU in gpuowl. The LL is slightly beyond the nominal range of CUDALucas, but PRP is theoretically within reach of gpuowl or Mlucas and TF is feasible in Mfaktx. Projected PRP time on a Radeon VII is 2.63 years, not recommended. Gpuowl V6.11-380 PRP timings:

Code:

2021-03-26 12:43:44 asr2/radeonvii4 2147483743 OK 20000 0.00%; 38636 us/it; ETA 960d 07:01; 304a08968e896b20 (check 23.14s)
2021-03-26 13:36:46 asr2/radeonvii4 2147483743 OK 100000 0.00%; 38636 us/it; ETA 960d 05:56; 0637bf5d33611a9d (check 22.85s)

**gigadigit** ~3.3gigabit experiments

There may be some naive interest in attempting these exponents, since they would potentially qualify for the largest

EFF prize. Sufficient TF is feasible with mfaktx and a fast gpu or a lot of patience. One

exponent has been trial factored to sufficient bit depth.

There is currently no GIMPS software suitable for P-1 factoring gigadigit exponents preparatory to a primality test attempt. As an experiment a copy of Gpuowl v6.11-219 was modified to raise the P-1 exponent limit as a function of fft length, sufficiently to permit P-1 attempts on gigabit exponents with its highest fft length. It was tested at a much smaller exponent and fft length, near the expanded P-1 bits/word limit, and failed to find a known factor, as one might expect. (George has identified a factor of 3 as a reason for slightly lower usable bits/word in the fft lengths for P-1.) P-1 factoring of gigadigit exponents will require a larger fft length than the 192M largest ever offered in Gpuowl. Estimated runtime for a gigadigit stage 1 P-1 run on a Radeon VII would be ~1-2 months per exponent. That is impractically long without robust error correction such as introduced in Gpuowl V7.2 P-1.

Mlucas and a select few versions of gpuowl could run the primality tests. Primality test duration is too long on any available consumer-grade hardware. There are severe reliability issues with very long LL tests.

Gpuowl v6.5-84 PRP3 (not recommended at an estimated 6.3 years on a Radeon VII; lacks PRP proof capability)

M3,321,928,097 1,000,000,001 decimal digits (This exponent is moot, as it has multiple known small factors)

Code:

FFT 196608K: Width 512x8, Height 256x8, Middle 12; 16.50 bits/word
2020-05-24 17:21:43 radeonvii3 3,321,928,097 20000 0.00%; 60053 us/sq; ETA 2308d 21:54; 1a05f0ca51fb8e7a
2020-05-24 18:41:56 radeonvii3 3,321,928,097 100000 0.00%; 60122 us/sq; ETA 2311d 12:24; 5b2cb77f57840bcc

A better test would have been a well trial factored

OBD candidate such as

3321928171.

The decline in bits/word is 1.09 over the range above, or about 0.838 bits/word per factor of ten on exponent.

Top of this thread

https://www.mersenneforum.org/showthread.php?t=24003
Top of reference tree:

https://www.mersenneforum.org/showpo...22&postcount=1