[QUOTE=flashjh;360752]What FFT lengths are you using when the restarts happen?
.......
[/QUOTE]

Got the data, but forgot to post it, till now-[INDENT]30.8M exponent, 1728K, GTX 570
37.5M exponent, 2048K, GTX 580

[/INDENT]

306.23 gives this-
[CODE]E:\CUDA\2.05-BETA\CL_2.05_A>cudalucas -r

device_number >= device_count ... exiting
(This is probably a driver problem)[/CODE]I'll move back up to something a bit more recent and see what happens.

EDIT: Shoot! 314.22 gives the same result with CUDALucas.......R49.

Back on driver 331.82. Seeming to run pretty well, again.

I have noticed that CUDALucas does not load the GPU's as heavily as mfaktc. My line-measured power consumption is down ~80 W with CL running on both cards. This is with nearly the OC core settings that mfaktc will run at. I still feel better about turning down the VRAM even from stock speeds to run CL, and it does affect the iteration time and the power consumption.

Regardless, with CL running on both cards, the whole system is pulling ~720 W with P95 running all eight cores of an FX-8350 on P-1, with 24 GB of RAM allowed. If the GPU's were running mfaktc, the power draw would be a bit over 800 W.

May I gently ask to also post GPU type, OS source name and release when you test new drivers?

Thanks :bow:

Luigi

[QUOTE=kladner;360788]306.23 gives this-
[CODE]E:\CUDA\2.05-BETA\CL_2.05_A>cudalucas -r

device_number >= device_count ... exiting
(This is probably a driver problem)[/CODE]I'll move back up to something a bit more recent and see what happens.

EDIT: Shoot! 314.22 gives the same result with CUDALucas.......R49.[/QUOTE]

320.18 is the first WHQL built on CUDA 5.5, which should be the earliest release driver that would work with this build of CUDALucas. I have all CUDA install from 3.2 and up. I could try building earlier versions if you're interested.

[QUOTE=kladner;360792]Back on driver 331.82. Seeming to run pretty well, again.

I have noticed that CUDALucas does not load the GPU's as heavily as mfaktc. My line-measured power consumption is down ~80 W with CL running on both cards. This is with nearly the OC core settings that mfaktc will run at. I still feel better about turning down the VRAM even from stock speeds to run CL, and it does affect the iteration time and the power consumption.

Regardless, with CL running on both cards, the whole system is pulling ~720 W with P95 running all eight cores of an FX-8350 on P-1, with 24 GB of RAM allowed. If the GPU's were running mfaktc, the power draw would be a bit over 800 W.[/QUOTE]

This is probably due to the amount of memcopy done back and forth between each iteration from host->device->host. As far as I have understood MfaktC, is that it keeps data in device mem. therefore activating the card alot more.

[QUOTE=ET_;360795]May I gently ask to also post GPU type, OS source name and release when you test new drivers?

Thanks :bow:

Luigi[/QUOTE]

Sorry. I was running in sloppy late-night mode.

Driver 331.82, latest WHQL
The cards are a Gigabyte GTX 570, and an Asus GTX 580.
Windows 7 Pro 64 bit, SP 1, all current Windows updates.
More on request if I missed something.

EDIT: Completed a DC on each card, matched residues on both. Before completion, the 580 log showed three batch file starts, or two restarts. This is an incomplete picture as it restarted several times in the previous evening. Some of these were spontaneous, while others had to do with switching out drivers.

[QUOTE=flashjh;360781]It's no problem. Changes are posted on sourceforge. If anything else needs updating, etc. just post it and I'll include it in a future commit.

I want to bring in the custom output formatting from mfactx, so I'll also look at line breaks, also. That will also allow for adding username and computer id to the results file line.[/QUOTE]

Thanks, Jerry. For some reason, I can sort out the lines more easily without the break, in spite of the rather wide box that requires.

EDIT: Another display driver restart, GTX 570 running CUDALucas_BETA_2.05_r49, 580 running mfaktc.
[CODE]C:/CUDA/CuLu/src/CUDALucas.cu(372) : cudaSafeCall() Runtime API error 30: unknown error.[/CODE]Aside from the CL batch file loop restart, this did not seem to cause any disruption. mfaktc appeared to be unaffected.

Well, it took me a wile to uncover this bug... I was beginning to think I am stupid :smile:, because for all of you it was working, but for me not...

Then suddenly it came... (I had to take the options one by one and play with them!)

I got so many errors about my cards not having enough memory, registers, wheels, purple lights, whatever, it even said I have minus few terabytes of RAM (!?!?), I was ready to give up... Then I tried to use the -info switch to see what freaking card he believes I have...

... And with -info switch it worked!

Here is where it did hit me! I have "PrintDeviceInfo=0" in the ini file ("who the hack need that? I know what kind of card I have!").

If you have "PrintDeviceInfo=0" in the ini file, then the program not only ignore printing them on screen, but also ignores reading them for himself... :razz:

[CODE]
e:\CudaLucas\CL0>cl205b_x64r49 -info

------- DEVICE 0 -------
name GeForce GTX 580
Compatibility 2.0
clockRate (MHz) 1564
memClockRate (MHz) 2004
totalGlobalMem 1610612736
totalConstMem 65536
l2CacheSize 786432
sharedMemPerBlock 49152
regsPerBlock 32768
warpSize 32
memPitch 2147483647
maxThreadsPerBlock 1024
maxThreadsPerMP 1536
multiProcessorCount 16
maxThreadsDim[3] 1024,1024,64
maxGridSize[3] 65535,65535,65535
textureAlignment 512
deviceOverlap 1

mkdir: cannot create directory `backup0': File exists
Using threads: norm1 256, mult 128, norm2 128.
Starting M37500769 fft length = 2048K
SIGINT caught, writing checkpoint. Estimated time spent so far: 0:39

[COLOR=Red]<it works perfectly>[/COLOR]

e:\CudaLucas\CL0>cl205b_x64r49

mkdir: cannot create directory `backup0': File exists
Using threads: norm1 256, mult 128, norm2 128.
over specifications Grid = 4096
try increasing norm1 threads (256) or decreasing FFT length (2048K)

[COLOR=Red]<freaks out>[/COLOR]

e:\CudaLucas\CL0>
[/CODE]

LaurV, Good find!

Found the problem in the init_device function.

I tested it, but please test again, thanks! :smile:

Committed the change and updated the .exe [URL="https://sourceforge.net/projects/cudalucas/files/2.05%20Beta/"]files[/URL].

Edit:
[QUOTE=Prime95;360761]I don't disagree, except that we are already vulnerable. Prime95 uses option 3 with "secret" code. Will we make matters any worse by giving CUDALucas the exact same vulnerability?[/QUOTE]

[QUOTE=chalsall;360762]Perhaps this vulnerability should be closed.[/QUOTE]

I like the idea of keeping the code open.

I think the changes to Primenet/G72 are a great option for now, but they require a reasonable amount of work, right? (And there is no guarantee that someone getting assignments would use the right option anyway). As such, I think leaving things as they are, may work best and once CUDALucas is stable and produces reliable results we can readdress the need for the secret code. Thoughts?

Also, CUDA 6 is going to (potentially significantly) change CUDALucas. This is one reason I don't think making big changes right now is a good idea.

Just for recording, and as a guy who makes a living from writing code, I have nothing against "secret" CRCs. Small function in a dll, cudaLucas can call to it and generate some key, which may also depend on the assignment key (if the work was "legally" reserved). It can call the function every 1M iterations, and every time add few characters to the key string. At the end, they would be easy to be verified without re-doing whole the work. We should not be afraid of "vulnerabilities", and does not need to be something very complicate. Prime95 is fine as it is.

My point is that people who [U]know[/U] how to exploit the vulnerability are too clever and too mature to use the exploit, they are "above" the "credit hunting fever". You don't get money for it (you can not "fake" a prime, for example - it will be verified by others immediately), and you even don't get "fame", contrarily, someone can realize you are cheating the system and you will have more to lose and suffer from the community. The "guarding" has to be against "childish" and "cmd*-like" stuff, like editing a text line and reporting two times, which anybody could do. (I wanted to write "any kid", but realized that kids today are so clever... hehe...)


(* for the new users here, "cmd" is a mersenneforum user who liked to do this kind of stupid things line adding all numbers with 37 digits to factorDB)