[QUOTE=storm5510;522204]Would this be a correct statement?[/QUOTE]

Yes. (correct statement, IMO).

Running that "lots of writing in files per second" stuff on SSD will bring you more safety if you have repeatedly crashes or electricity breaks, but will significantly reduce the life of your SDD.

[QUOTE=storm5510;522204]I have been running James Heinrich's project using a RAM-drive.[/QUOTE]For everyone else, that would be my [url=https://www.mersenne.ca/tf1G.php]TF >1000M[/url] subproject, which tends to have runtimes of few seconds rather than minutes/hours of typical mfaktx work.
There's no reason to stop using the RAMdrive. While SSDs are subject to wear with repeated writes, discussions elsewhere have argued that you're not likely to significantly shorten the useful life of a modern SSD by rewriting worktodo/results every second. I personally prefer to avoid SSD wear where possible. Wear issues aside, access to/from RAM will naturally always be faster and subject to zero wear. The only downside is the potential for data loss in an unprotected power outage (or unexpected crash-reboot). Since you have the RAMdrive set up already I would continue to use it for short-runtime, high-turnover workloads.

As long as you are prepared for them to die I wouldn't worry about a 250GB SSD. I can get them for just over £25 currently. By the time it would wear out it would be cheaper still.

[QUOTE=James Heinrich;522206]...The only downside is the potential for data loss in an unprotected power outage (or unexpected crash-reboot). Since you have the RAMdrive set up already I would continue to use it for short-runtime, high-turnover workloads.[/QUOTE]

Thank you all for your replies. :smile:

In each batch cycle, I have a batch line which duplicates the [I]worktodo [/I]file to a folder on the hard drive which is overwritten on each repetition. With the SSD, I have a smaller mechanical drive which I will add as extra storage space for things I do not access very often. I will send my work duplication to it. Any modification to the batch file itself, I duplicate to the folder which the RAM-drive loads from upon startup. Power outages are rare here, but they do happen. I think I cover everything fairly well. I am not fond of the idea of having a group of assignments being lost and not having a way to retrieve them.

[QUOTE=storm5510;522262]I am not fond of the idea of having a group of assignments being lost and not having a way to retrieve them.[/QUOTE]It might bother you personally, but the project doesn't really care, since the assignments will be recycled after 10 days if results aren't submitted.

Mfaktc Less-Classes Start Error
 

This pertains to my older HP running Windows 7 Pro x64 and a GTX-750Ti GPU. I started receiving an error when I attempt to run the less-classes version of [I]mfaktc[/I]:

[B]ERROR: cudaStreamCreate() failed for stream 0
cudaGetLastError() returned 11: invalid argument[/B]

I installed the latest driver set. No help. The only hardware difference is an additional 4 GB of RAM.

[U]Note[/U]: The regular version of [I]mfaktc[/I] is not affected and runs normally. Both are the CUDA 10 variants. Everything in the configuration file is set to default values.

Ideas?

Have you rebooted since updating graphics drivers? I've seen mfaktc give a bunch of different weird errors, even intermittently pass self tests without error in between attempts which errored out, when drivers were updated without reboot (on Linux anyways).

[QUOTE=hansl;523808]Have you rebooted since updating graphics drivers? I've seen mfaktc give a bunch of different weird errors, even intermittently pass self tests without error in between attempts which errored out, when drivers were updated without reboot (on Linux anyways).[/QUOTE]

Sometimes, the update application requires a reboot, and other times, not. This time, it did not request it. I rebooted it anyway.

I have the CUDA 80 archives stored away. I switched to it for the less-classes. No more problem.

I've made the mfaktc makefile more user-friendly. The latest stable version is hard-coded to use CUDA 6.5 and will return an "Unsupported gpu architecture" error on newer systems. Users who wish to compile on newer versions would have to manually edit the NVCC flags.

Therefore, the updated makefile supports the following arguments:
[LIST][*][c]make build=cuda65[/c] for CUDA 6.5[*][c]make build=cuda80[/c] for CUDA 8.0[*][c]make build=cuda100[/c] for CUDA 10.0[/LIST]
It will still default to CUDA 6.5 if no version is specified.

Update: uploaded a new version to fix naming inconsistencies.

I built for Linux with CUDA 10.1 (attached). Hopefully this can be useful for others, particularly the recent [URL="https://mersenneforum.org/showthread.php?t=24646"]Google Colaboratory[/URL] thread.

I have made one small change to params.h and mfaktc.ini to increase the max and default GPUSieveSize to 2047

Based on this:
[QUOTE=kriesel;508523]
...
29 Some RTX20xx owners have modified the tuning variable limits, recompiled, and obtained performance gains of several percent, with diminishing incremental returns as GPUSieveSize grows to GB [URL]https://www.mersenneforum.org/showpost.php?p=507040&postcount=3071[/URL]
Maximum gpusievesize was found to be 2047MB after program modification.
...
[/QUOTE]

Hi,

unless you're really sure about the increased sieve size limit I suggest to stay with 1024...
"Doesn't crash" and "passes the builtin selftest" doesn't prove that 2047 is OK. 2048 crashes hard because of an (integer) overflow...

Oliver