mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Hardware > GPU Computing

Reply
 
Thread Tools
Old 2019-07-24, 15:35   #3180
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

100011101101102 Posts
Default

Quote:
Originally Posted by storm5510 View Post
Would this be a correct statement?
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.

Last fiddled with by LaurV on 2019-07-24 at 15:37
LaurV is online now   Reply With Quote
Old 2019-07-24, 15:39   #3181
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

62528 Posts
Default

Quote:
Originally Posted by storm5510 View Post
I have been running James Heinrich's project using a RAM-drive.
For everyone else, that would be my TF >1000M 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.

Last fiddled with by James Heinrich on 2019-07-24 at 15:44
James Heinrich is online now   Reply With Quote
Old 2019-07-24, 16:04   #3182
henryzz
Just call me Henry
 
henryzz's Avatar
 
"David"
Sep 2007
Cambridge (GMT/BST)

2×2,897 Posts
Default

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.
henryzz is offline   Reply With Quote
Old 2019-07-25, 02:30   #3183
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
U.S.A.

32×199 Posts
Default

Quote:
Originally Posted by James Heinrich View Post
...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.
Thank you all for your replies.

In each batch cycle, I have a batch line which duplicates the worktodo 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.
storm5510 is offline   Reply With Quote
Old 2019-07-25, 03:01   #3184
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

2×1,621 Posts
Default

Quote:
Originally Posted by storm5510 View Post
I am not fond of the idea of having a group of assignments being lost and not having a way to retrieve them.
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.
James Heinrich is online now   Reply With Quote
Old 2019-08-17, 00:01   #3185
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
U.S.A.

110111111112 Posts
Default 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 mfaktc:

ERROR: cudaStreamCreate() failed for stream 0
cudaGetLastError() returned 11: invalid argument


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

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

Ideas?
storm5510 is offline   Reply With Quote
Old 2019-08-17, 00:40   #3186
hansl
 
hansl's Avatar
 
Apr 2019

5×41 Posts
Default

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).
hansl is offline   Reply With Quote
Old 2019-08-19, 00:26   #3187
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
U.S.A.

32·199 Posts
Default

Quote:
Originally Posted by hansl View Post
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).
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.
storm5510 is offline   Reply With Quote
Old 2019-08-23, 21:23   #3188
ixfd64
Bemusing Prompter
 
ixfd64's Avatar
 
"Danny"
Dec 2002
California

34·29 Posts
Default

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:
  • make build=cuda65 for CUDA 6.5
  • make build=cuda80 for CUDA 8.0
  • make build=cuda100 for CUDA 10.0

It will still default to CUDA 6.5 if no version is specified.

Update: uploaded a new version to fix naming inconsistencies.
Attached Files
File Type: zip mfaktc-makefile.zip (1.5 KB, 73 views)

Last fiddled with by ixfd64 on 2019-08-25 at 01:15
ixfd64 is online now   Reply With Quote
Old 2019-09-04, 18:28   #3189
hansl
 
hansl's Avatar
 
Apr 2019

5×41 Posts
Default

I built for Linux with CUDA 10.1 (attached). Hopefully this can be useful for others, particularly the recent Google Colaboratory 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:
Originally Posted by kriesel View Post
...
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 https://www.mersenneforum.org/showpo...postcount=3071
Maximum gpusievesize was found to be 2047MB after program modification.
...
Attached Files
File Type: gz mfaktc-0.21.linux64.cuda10.1.tar.gz (1.52 MB, 101 views)

Last fiddled with by hansl on 2019-09-04 at 18:29
hansl is offline   Reply With Quote
Old 2019-09-11, 17:43   #3190
TheJudger
 
TheJudger's Avatar
 
"Oliver"
Mar 2005
Germany

2·3·5·37 Posts
Default

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

Last fiddled with by TheJudger on 2019-09-11 at 17:43
TheJudger is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
mfakto: an OpenCL program for Mersenne prefactoring Bdot GPU Computing 1668 2020-12-22 15:38
The P-1 factoring CUDA program firejuggler GPU Computing 753 2020-12-12 18:07
gr-mfaktc: a CUDA program for generalized repunits prefactoring MrRepunit GPU Computing 32 2020-11-11 19:56
mfaktc 0.21 - CUDA runtime wrong keisentraut Software 2 2020-08-18 07:03
World's second-dumbest CUDA program fivemack Programming 112 2015-02-12 22:51

All times are UTC. The time now is 07:21.

Mon Jan 18 07:21:37 UTC 2021 up 46 days, 3:32, 0 users, load averages: 2.26, 2.07, 2.01

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.