[QUOTE=flashjh;360733]r48 is up with the updated display and results file output

So the Windows version allows you to use the interactive mode?[/QUOTE]
Yes. Win 7 Pro, 64 bit. 331.82 drivers.

I'll get r48 if that is on Sourceforge now.

EDIT: Got r48. Should have refreshed the page the last time I looked.

[QUOTE=kladner;360732]I ran the r47 version (not debug) overnight on both cards: 570 and 580. Event viewer shows two display driver restarts.

[/QUOTE]

I get device driver restart witn 2.03 and latest drivers too on both 580 and 590 boards. I found 306.23 to be the most stable driver for 5xx boards.

What FFT lengths are you using when the restarts happen?

On my current 580 system with the latest drivers (and several of the last few) I get restarts on the following FFT lengths:[CODE]
CUDALucas -cufftbench 3360 3360 6
CUDALucas -cufftbench 5040 5040 6
CUDALucas -cufftbench 5670 5670 6
CUDALucas -cufftbench 6720 6720 6[/CODE] I discovered these when I ran the .bat file I attached above. I have more 580s to test this on, but I haven't yet. I have tried updating and downgrading drivers with no luck. I have not rolled back to 306.23, I may try and see if it helps.

Anyone notice if these match the ones you're having trouble with or are they different?

[STRIKE]So the interactive does not work on my system. Anyone have any ideas as to what setting could be causing that? If I press a key with interactive enabled, I can see it (them) on the screen, but the program pauses and the only way to restart is to ^c and restart.
[/STRIKE]

I realized you have to press ENTER after the key press :redface:

EDIT:[QUOTE=kladner;360735]EDIT: Got r48. Should have refreshed the page the last time I looked.[/QUOTE]

I just put it there a while ago, it was probably after you looked the first time.

[QUOTE=flashjh;360724]I agree, but was falsely under the impression that the shift was what was missing to allow 1st-time and DCs on the same exponent. Your suggestion is heard loud and clear, but we need to know what ideas can be implemented to allow for both checks. Ideas?[/QUOTE]

We have 3 options that I see:

1) Disallow CUDALucas from double-checking CUDALucas results (the status quo).
2) Allow double-checks as long as the shift counts are different. The downside: it is real easy to forge a double-check.
3) Add a security code to the CUDALucas final result output (a simple hash of the exponent and shift count). This code could be secret, which isn't allowed if CUDALucas is GPL. Those building executables would be entrusted with the secret code. Or, the code can be public. At least a forger of results has to go to the trouble of reading C code.

There is an optional add-on to options 2 and 3. The Primenet server and/or GPU72 server can be upgraded to only give double-check exponents that were first tested by prime95.

[QUOTE=Prime95;360756]1) Disallow CUDALucas from double-checking CUDALucas results (the status quo).

There is an optional add-on to options 2 and 3. The Primenet server and/or GPU72 server can be upgraded to only give double-check exponents that were first tested by prime95.[/QUOTE]

I would like to argue that Option #1 is the only one which guarantees the integrity of the GIMPS knowledge of the status of MPs. Or, at least, doesn't leave it wide-open to attack. There are rarely times where security through obscurity is warranted, but this might be one of them. [COLOR="White"](Anyone good with a de-compiler / dis-assembler could still break this thing, though...)[/COLOR]

Towards the end of not wasting resources, I will add to the top of my todo list to implement an additional option on the GPU72 manual assignment page: For CPU, For GPU.

[QUOTE=chalsall;360759]I would like to argue that Option #1 is the only one which guarantees the security of the GIMPS knowledge of the status of MPs.[/QUOTE]

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=Prime95;360761]Will we make matters any worse by giving CUDALucas the exact same vulnerability?[/QUOTE]

Perhaps this vulnerability should be closed.

[QUOTE=kladner;360735]Yes. Win 7 Pro, 64 bit. 331.82 drivers.

[/QUOTE]

Updated driver to 331.93 BETA. No noticeable difference.

r48 seems determined to output each check point on two line, no matter how wide the CMD box.

[QUOTE=kladner;360775]Updated driver to 331.93 BETA. No noticeable difference.

r48 seems determined to output each check point on two line, no matter how wide the CMD box.[/QUOTE]

It always scrolled over two lines anyway, so I added a newline to make it easier to read. [STRIKE]Are you on windows or linux?[/STRIKE]

Edit: I'll remove the newline on the next commit.

[QUOTE=flashjh;360776]It always scrolled over two lines anyway, so I added a newline to make it easier to read. [STRIKE]Are you on windows or linux?[/STRIKE]

Edit: I'll remove the newline on the next commit.[/QUOTE]

No biggy. I just wanted to confirm that it is not a malfunction.

EDIT: Can it be made an option, to split or not to split?

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.