[QUOTE=Brain;289692]So the code change did have an effect?[/QUOTE]

Yes, it worked great in initial testing. I have another exponent that will finish in about 13 hours. I'll let you know.

Thanks again.

[QUOTE=flashjh;289699]Yes, it worked great in initial testing. I have another exponent that will finish in about 13 hours. I'll let you know.

Thanks again.[/QUOTE]

Ok, it definitely continues to the next line in the batch files now.

I have one issue though... I remote into the computer that's running CUDALucas right now. Anytime I'm logged in remotely the batch file fails because it can't find the video card for the next exponent. Is there any way to resolve this without restarting - is there a way to close the remote Windows session and give control back to the local video card?

Thanks.

[QUOTE=LaurV;289124]The first two DC's completed with CudaLucas1.49, drv4.0, cc2.0:

M( 26026433 )C, 0x457f73d49f90b822, n = 1572864, CUDALucas v1.49
M( 26176441 )C, 0x19283a19b247ba__, n = 1572864, CUDALucas v1.49

First is a match. Second is not (therefore I masked it). Both results coming from a gtx580 standard clock (no overclock this time). I am not going to repeat the second test as long as it is not confirmed as bad by a p95 run. After someone will clear the exponent, and if my test proved bad, I will repeat it to see if it come from the program.

edit: another small observation, the -c switch does not work for the screen, like in the older versions (I did not check if it really works for the checkpoint files too, but the screen effect is the first one observable) used to work. For -c30000, v1.49 still outputs to the screen every 10k iterations.[/QUOTE]

Since I have been having so many mismatches I ran your M( 26026433 ) to test my setup. First time was a mismatch:

[CODE]
M( 26026433 )C, 0x190df3dc67d21885, n = 1572864, CUDALucas v1.50
[/CODE]

So I reinstalled all drivers and made sure nothing was overclocked. Second time was a mismatch also:

[CODE]M( 26026433 )C, 0xee1b55e2b3e0c8b5, n = 1572864, CUDALucas v1.50[/CODE]

I was getting good checks for a while... now I don't know what is wrong. It can run smaller exponents just fine. I'll have to keep testing to see.

Is there a test than can be run to see if something is wrong?

Something wrong?
 

I need 2-3 more days to finish my first 1.49/1.50 hybrid test.

[QUOTE=flashjh;289990]
Is there a test than can be run to see if something is wrong?[/QUOTE]

I was getting another 3 matches and one mismatch in this time. I am sure my problem is overclocking of the GPU, that is why I am doing more DCLL and less (almost none) LL-first-time, as the probability of failure is high here. It happened to me in the past to repeat 3-4-5 times a DC and get 3-4-5 different residues. I gave up of that (unprofitable) activity and lowered the clock. I am still pushing my cards (750/781 MHz) to 800, 820, and seldom to 850. I used to go to over 900 and close to 950 for tests, and nothing seems reliable at that speeds.

I think the good step to do for you, after you exclude the overclocking reasons, is to [B]do a mem test[/B] for your graphic card. Make sure your graphic memory is zero-defects.

edit:
Not so many people know, but the graphic-cards industry is the only industry which ACCEPTS memory with defects. There is a standard that classifies the memories according with of how many ppm defects they have. (I work in an electronics factory, we produce lcd modules and touch terminals, human-machine interfaces for industrial use, etc).

The reason is that the human eye does not perceive the colors very accurate, and a defective pixel on your screen which shows "blue 249" instead of "blue 253" (bit 2 always in zero) will never be spotted by the human eye. In the past it was very common for graphic cards to have defective bits, which would translate into "unobservable" defective pixels on your screen. Manufacturers did that in their quest to produce cheap video cards, they digested memory IC's that were "refused" by the other RAM consumers. As the technology progressed, the probability to get a video card with defective pixels is lower, but still exists. Have you ever asked yourself why a tesla is 3-4 times more expensive then a 580? (that is, 2000 dollars, instead of 550 dollars for a 580 with 3 gigs). That is not the amount of memory (6 gigs for a tesla, instead of 3 for a gtx580) for sure, because a gtx580 with 3 gigs is just 50-80 dollars more then a gtx580 with 1.5 gigs. Also, gtx580 it has 512 cores, and tesla has only 448, there is exactly the same core of the gx110 chip, for geforce it was improved a bit and called gx114, and for tesla the second memory channel was added, hence the higher communication speed and memory area. Does this justify the triple-quadruple price? No. The difference come from the ECC memory type used for tesla, which is super-stress-tested for hours and guaranteed to be zero-defects. That is not true for gtx series, or say, it highly depends of the manufacturer, what type of memory you have there, and if it is zero-defects or not. For video and games it does not matter, and you even can get a better result with an overclocked geforce than with a tesla, as teslas usually run at lower clock speed and you can not oc them too much, contrary to a gtx580 which you can oc up to 30% or more, or a gtx560 which come already at 900, 950 or 1G overclocked. But for prime crunching it matters.

Also, it matters more for cudalucas than for mfaktc, as the last one does not use the memory of the card too much (almost nothing), but CL is card-mem-intensive (you can see this easy with gpu-z).

How about coding up a CUDALucas torture test? It should be easy to implement. Prime95 sources have a list of exponents and expected residues after a certain number of LL iterations.

Good idea, but first, a rock-solid version should be identified. That, if the hardware is totally stable, will never ever produce wrong residues.

After that is settled, one particular question should be answered: what exactly is stressed ? GPU's shader domain ? Or the memory ?
I have a feeling it's more mem than shader stress testing.

[QUOTE=LaurV;290059]Also, it matters more for cudalucas than for mfaktc, as the last one does not use the memory of the card too much (almost nothing), but CL is card-mem-intensive (you can see this easy with gpu-z).[/QUOTE]

LaurV... You raise a very interesting and important point.

In economic terms, what will the consumer bear?

For those who only want to play games (the majority), it doesn't matter if a few pixels are a little wrong in the colors for that single frame which passes by in something like 1/60th of a second. They won't even notice.

For those who are trying to use consumer kit for serious math, an error is a big deal.

Hmmm... Something to think seriously about....

Well consider that the majority of tests have turned out well so far, and certainly nVidia wouldn't advertise the Compute Compatibilty and overall CUDA-ness of the GTXs if they weren't capable of doing accurate math. Having lightly been following this, it seems the only major difference is the CL version (meaning that previous versions at the same hardware settings have been successful, correct LaurV?).

[QUOTE=Dubslow;290156]Well consider that the majority of tests have turned out well so far, and certainly nVidia wouldn't advertise the Compute Compatibilty and overall CUDA-ness of the GTXs if they weren't capable of doing accurate math. Having lightly been following this, it seems the only major difference is the CL version (meaning that previous versions at the same hardware settings have been successful, correct LaurV?).[/QUOTE]

Sigh...

Grasshopper does not appreciate that he (and we) might be lied to....

Well okay, even ignoring the advertising, the fact remains that many different GT*s have turned in many different successful double checks with various versions of CUDALucas.