Thanks.

Trouble was, I was nowhere near when CUDALucas (and Windoze) quit the first time.....so the results file is mersarch.txt. I don't think I had that, will check later this week.

Will have to try a simple command line and see what happens. Insufficient memory is a definite possibility, with P95 doing P-1 and mfaktc also running.

[QUOTE=Christenson;270497]
Insufficient memory is a definite possibility, with P95 doing P-1 and mfaktc also running.[/QUOTE]

I had "not enough memory" exits due to GPU memory only so in that case P95 would not matter. Windows would probably just start swapping if it were main memory...

I ran the command line alone tonight...here's what I got:
>CUDALucas.cuda4.0.sm_13.WIN64.exe -t10000 25xxxxxx
CUDALucas: inconsistent RI header (initial line)
CUDALucas: Resuming from Checkpoint file c25xxxxxx
something wrong; error message, if any, already printed

>
The contents of the t file and the c file don't make sense to wordpad; and the file sizes don't match:
t25xxxxxx is 16,777,240 bytes
c25xxxxxx is 16,711,680 bytes

So, is the situation recoverable? Or should I just start over on this test?
By the way, I like the idea of making multiple backup files, like P95 does; then corruption of one file can be dealt with by going one checkpoint further back. An hour or two's loss is really zero; I can only visit this machine once a day.

[QUOTE=Christenson;270614]So, is the situation recoverable? Or should I just start over on this test?
By the way, I like the idea of making multiple backup files, like P95 does; then corruption of one file can be dealt with by going one checkpoint further back. An hour or two's loss is really zero; I can only visit this machine once a day.[/QUOTE]

As far as I understand t and c are two backup files. If one is corrupted you could remove it and let cudalucas try to restart from the other.

[QUOTE=apsen;270619]As far as I understand t and c are two backup files. If one is corrupted you could remove it and let cudalucas try to restart from the other.[/QUOTE]

Given that one was shorter than the other, I took the longer one from a backup, the t file, copied it, and renamed it c25xxxxxx.

After a few minutes, CUDALucas told me it was re-starting on iteration 18xxxxxx. With luck, it will finish an LL-D soon. So it looks very much like the restart succeeded, but I'll definitely feel better when the residues actually match.

[QUOTE=Christenson;270779]Given that one was shorter than the other, I took the longer one from a backup, the t file, copied it, and renamed it c25xxxxxx.
[/QUOTE]

I do not think you need to rename it. Just remove the corrupted one. But I did not really verify this.

Might or might not have needed to rename it...but it worked on the first try, so I let it rip....when I get to the machine again I'll see if it finished...

[QUOTE=Brain;270170]I've run 3 successfull 2M DCs on my GTX 560 Ti @ 280er driver and CUDA 4er libs. Now starting 4M first time tests.[/QUOTE]

Double checking 28258603 I'm getting different results with 1.2b and 1.3alpha_eoc.

Success!!!
Processing result: M( 25012619 )C, 0x4f69b693878axxxx, n = 2097152, CUDALucas v1.2b-test
LL test successfully completes double-check of M25012619, CUDALucas v1.2b-test

Hardware was GTX480.

1 down, a million to go....what's the n=2097152 mean?

[QUOTE=Christenson;271241]what's the n=2097152 mean?[/QUOTE]
The FFT length used, 2048K in this case.

[QUOTE=Christenson;271241]what's the n=2097152 mean?[/QUOTE]

Yes divide that number by 1024 and it should give you the FFT length used.