[QUOTE=storm5510;467953]I had the errors below occur over a 30 minute period yesterday evening:

[CODE]ERROR: cudaGetLastError() returned 4: unspecified lauch failure
ERROR: cudaGetLastError() returned 30: unspecified lauch failure[/CODE]

Not knowing the exact source, I restarted the machine and then updated the drivers. This 'appears' to have solved the problem. I have been running [I]mfaktc[/I] ten months and this is the first issue to arise. The hardware is a GTX-480 with Windows 10 Pro, x64.

Does anyone have any ideas regarding the cause?[/QUOTE]

[U]One possibility[/U]: aging hardware :sad:

Oliver

Blown capacitors are a frequent culprit. I had a card blow a cap. Fortunately, it was under warranty. I have replaced caps in an LCD monitor, with guidance from a YouTube tutorial.

"Blown" is descriptive in this case. Parts fail by spewing electrolyte. Failed parts are usually easy to spot.

[QUOTE=TheJudger;468110][U]One possibility[/U]: aging hardware :sad:

Oliver[/QUOTE]

This machine, with the exception of the GTX-480, is three months old.

After my initial posting about these errors, I noticed a Notepad document was open. It was the [I]results.txt[/I] file. It had been loaded for several hours. I was under the impression that Notepad opens a 'copy' of the original, and then closes it. This must not be the case. I rarely open it with [I]mfaktc[/I] running, but sometimes, I do when I see the program will not attempt a 'write' operation for a few minutes.

Bottom line, I believe I created my own error by not paying attention. After the restart, and the driver update, these errors did not occur again. More than likely, the update was not needed, but it had been a while since I updated the drivers. I always get them from NVidia.

The same sample on ASUS 1080 Ti ROG Strix OC

CUDA version info
binary compiled for CUDA 8.0
CUDA runtime version 8.0
CUDA driver version 9.10

CUDA device info
name GeForce GTX 1080 Ti
compute capability 6.1
max threads per block 1024
max shared memory per MP 98304 byte
number of multiprocessors 28
clock rate (CUDA cores) 1683MHz
memory clock rate: 5505MHz
memory bus width: 352 bit

Automatic parameters
threads per grid 917504
GPUSievePrimes (adjusted) 82486
GPUsieve minimum exponent 1055144


got assignment: exp=66362159 bit_min=75 bit_max=76 (115.31 GHz-days)
Starting trial factoring M66362159 from 2^75 to 2^76 (115.31 GHz-days)
k_min = 284642124606840
k_max = 569284249220360
Using GPU kernel "barrett76_mul32_gs"

Date Time | class Pct | time ETA | GHz-d/day Sieve Rate (M/s)
Oct 19 22:52 | 9 0.3% | 6.507 1h43m | 1594.85 82485 9468.4

[QUOTE=AK76;470123]...
CUDA device info
name [COLOR=Blue][B]GeForce GTX 1080 Ti[/B][/COLOR]
compute capability 6.1...
[/QUOTE]

I considered going this route a while back but I will not. It is not so much the cost as it is the power consumption. Since I started using my old GTX 480 my utility costs have risen. Based on the APC data, it is using 220W. The GTX 1080 is rated at 180W. This is what I plan to buy within the next month. Yes, the performance is lower than the "Ti." This does not concern me. I simply want a little less load on my APC and still have decent performance. :smile:

Minimum exponent
 

Just ran across the following in V0.20 mfaktc on win 64.

[URL]http://www.mersennewiki.org/index.php/Mfaktc[/URL] appears to be in error about exponent minimum, stating 100000 (10^5) while program v0.20 with -v 1 or higher warns about minimum exponent 1000000 (10^6). With -v 0 it gives no indication why it's skipping worktodo entries. -v 1 output example:

WARNING: exponents < 1000000 are not supported!
Ignoring TF M999773 from 2^53 to 2^60!
WARNING: ignoring line 1 in "worktodo.txt"! Reason: invalid data
got assignment: exp=1000541 bit_min=66 bit_max=70 (224.06 GHz-days)
Starting trial factoring M1000541 from 2^66 to 2^67 (14.94 GHz-days)
k_min = 36873539559780
k_max = 73747079125031
Using GPU kernel "barrett76_mul32_gs"

Would someone with v0.21 installed please try to duplicate and post here whether its behavior differs regarding lower exponent limit or warning when -v is set to 0?

Who maintains the mersennewiki page for mfaktc?

There are different compilations of mfaktc 0.18, 0.20, and 0.21, some of them going as low as 10k, or (the 0.18 "bcp" version) to even 2k. The official 0.21 which I use goes down to 100k. You should not decrease the limit if you don't know what you are doing, I mean it is not as simple as changing the definition in the ".h" file and recompile, there are a couple of problems associated with it, for example, if the exponent goes down, the number of candidates for the same bitlevel increases (all factors are of the form q=2kp+1, where p is the exponent in m=2^p-1, and when p gets smaller, there are more numbers in the 2^n and 2^(n+1) interval. This creates problems with sieving and storing them. For example, if p=101, then 2p+1 is 203, and if you search for 12-bit factors of 2^101-1 (i.e. factors between 2^11 and 2^12) there are 2^11/203=2048/203=~10 candidates to look at, but if you search 12 bits factors of 2^67, then 2p+1 is 135, and you will have 2048/135=15 candidates to look at. That is why you need longer time to factor the same bitlevel when the exponent is smaller. If the exponent is too small, and the bitlevel too high, you will not have memory in the GPU to store all candidates for sieving, and you either need to sieve with the CPU (slow), or implement a different segmented GPU siever.

Also, when sieving, additional precaution needs to be in place to avoid eliminating factors. For example, if you sieve the classes with the first 10 million primes (this means primes under about 180M), you need additional tests of those primes, before using them for sieving, like, say, one of them may be a factor of the number you try to factor, and that will be lost by sieving.

In fact, I tried in the past to "push" Oliver into eliminating a couple of restrictions from mfaktc, but he was busy with new things and didn't really listened to the old guy on the other side of the globe...

For example, the most important, restriction of the exponent being prime, should be eliminated (substituted with a warning, and let the user decide, right now, the program is aborting). This may help us to factor some small mersenne numbers with composite exponent from FDB (not of interest for GIMPS, but of interest for other people, see former discussions here around). The drawback is that, in case of composite exponents, some factors are not of the form that mfaktc is searching, and they will be missed. But we do not report "no factors" for these exponents anywhere, so it doesn't matter, as long as other factors may be found. Oliver however, does not like to launch in the wild a program that can miss factors :razz:

Other important restriction is related to the exponent lowest limit (the reason of this post). By allowing a lower limit in the current version of the program, assuming you have memory in your GPU to store the classes for sieving, or assuming that you sieve with the CPU, then all it can happen is that you miss a factor which is [U]under 29 bits[/U]. This I can prove. But the factors of under 29 bits were all already found, most probably, and there is no reason why lowering the exponent limit should be delayed anymore. Again, Oliver will argue that such program will miss factors (assuming you start factoring some very low exponent from scratch, without any previous knowledge about it from the GIMPS' database).

Time will see...

[QUOTE=kriesel;470947]
Would someone with v0.21 installed please try to duplicate and post here whether its behavior differs regarding lower exponent limit or warning when [B]-v[/B] is set to 0?
[/QUOTE]

There is nothing in [I]mfaktc.ini[/I] for v0.21 which references "-v."

[QUOTE=storm5510;471011]There is nothing in [I]mfaktc.ini[/I] for v0.21 which references "-v."[/QUOTE]

That's true of the ini file and readme.txt for v0.20 also. But it is listed if you run mfaktc -h.
Try that.

[QUOTE=kriesel;471215]That's true of the ini file and readme.txt for v0.20 also. But it is listed if you run mfaktc -h.
Try that.[/QUOTE]

I knew there were some command-line switches, but did not know how to list them. Thanks! :smile:

[QUOTE=kriesel;470947]...Would someone with v0.21 installed please try to duplicate and post here whether its behavior differs regarding lower exponent limit or warning when -v is set to 0?[/QUOTE]

There is a "no-classes" variant of [I]mfaktc[/I] on James Heinrich's [I]mersenne.ca[/I] site which updates the screen at intervals of 1.0% to 1.1% instead of 0.1%. It is v0.21. Not sure about anything for CUDA 65. The link is on his assignment page.

I tried the -v switches on my hardware. They had no affect. Of course, it is a bit out-of-date.