[QUOTE=cuBerBruce;429190]I got a mismatch on M52534751. Somehow, LaurV has already confirmed my residue.[/QUOTE]
See [URL="http://www.mersenneforum.org/showthread.php?p=428291"]here[/URL]. You are late. But welcomed. :razz:
I am also 85% on the way of the other of your assignment, and I will hold if a mismatch, but report if match (in which case your work will be a waste).

[QUOTE=Mark Rose;429195]Mismatches are expected though... that's why these are being tested ahead of schedule.[/QUOTE]

Whew, what a relief :smile:

[QUOTE=LaurV;429293]See [URL="http://www.mersenneforum.org/showthread.php?p=428291"]here[/URL]. You are late. But welcomed. :razz:
I am also 85% on the way of the other of your assignment, and I will hold if a mismatch, but report if match (in which case your work will be a waste).[/QUOTE]

Next time, please get an assignment ID for your work so MadPoo doesn't include the same exponents in his next list that he makes, as what happened here.

Edit: I've suspended work on M54627319 to wait and see if LaurV gets a match, and started working on M55415323 instead. As far as I can tell, nobody else is working on that one.

[QUOTE=Dubslow;429200]Yes, a bad habit of his. Several years ago he had some issues, mostly relating to test versions of CuLu IIRC, that caused several consecutive bad results. Since then he refuses to turn in mismatches unless he verifies them himself (still only reports it once though) or someone else does too, even though the overwhelming majority of his results since then have been consistently good.
[/QUOTE]

I wish *he* thought his results were good... he still checks in self-verified work that I (being OCD about it at this point) will then do an independent triple-check. He hasn't had a bad result in years, but he still insists on verifying all of his own work. :razz:

I think most of his self-verified work these days involves one clLucas and one CudaLucas run... so at least one of them is doing a shift-count, otherwise it wouldn't accept it as a verifying run... I know he'll just tell me that I don't have to do an independent check... sigh... He could double his chances of finding the next prime if he had more trust in his machine. :smile:

If he was suspicious of the reliability at all, I'd recommend doing a double-check of someone else's work about 5% of the time (or pick whatever %), just to know it's still on course.

[QUOTE=kladner;429266]Yes, at least to the first:[INDENT](from cudalucas.ini)
# RoundoffTest is a binary option. If set to 1, roundoff errors are checked at the
# beginning of each test.
# Default 0

RoundoffTest=1
[/INDENT]I always have had this set. I think I have seen it in action once. Still, proven bad results show up.[/QUOTE]

I'll go out on a limb and speculate that 95% of all bad results are memory related... whether it's a bad stick in general, or it's being overclocked beyond what's safe and sane.

That's just anecdotal... I have nothing to back it up at all, but now I do have a thought to check the history of bad results and find out if the CPU was overclocked at least... if so it's a good chance the memory might be. At least on GPUs that is. I'm not sure all of the data I need is present.

I did some previous looks at whether error rates were more/less with certain app versions, but I never lumped all GPU and all CPU into opposing "teams" and compared their aggregate error rates. I do wonder if one or the other is more error prone... I'd guess GPU memory is more likely to do strange things, but that sounds like I'm picking on GPUs for no reason, and I could be wrong. :smile:

[QUOTE=Madpoo;429320][B]I'll go out on a limb and speculate that 95% of all bad results are memory related... whether it's a bad stick in general, or it's being overclocked beyond what's safe and sane.[/B]

That's just anecdotal... I have nothing to back it up at all, but now I do have a thought to check the history of bad results and find out if the CPU was overclocked at least... if so it's a good chance the memory might be. At least on GPUs that is. I'm not sure all of the data I need is present.

I did some previous looks at whether error rates were more/less with certain app versions, but I never lumped all GPU and all CPU into opposing "teams" and compared their aggregate error rates. I do wonder if one or the other is more error prone... I'd guess GPU memory is more likely to do strange things, but that sounds like I'm picking on GPUs for no reason, and I could be wrong. :smile:[/QUOTE]
I concur with the bolded line, if GPU RAM is included in the list of possible culprits. I suspect that my bad results could result from [B]not reducing the VRAM clock enough. [/B]This is one of the parameters which may be reset in MSI Afterburner after a timeout or crash. (Defining "crash" as an event which locks the GPU core to 405 MHz.) Core clock may revert to the BIOS value, too. Voltage doesn't seem to reset.

EDIT: I don't think it is safe to run CUDALucas with a looping batch file. Anytime it stops for any reason one ought to check the core and VRAM clocks. This is in the context of my moderately informed opinion that consumer GPUs generally have the memory clock too high to work reliably in CuLu. That is, nVidia specifies too high for the quality of memory used on most cards. Factory OCd cards may need the core clock reduced, too.

[QUOTE=Madpoo;429319]I wish *he* thought his results were good... he still checks in self-verified work... <snip>.[/QUOTE]
You won't believe, but running tests in parallel, actually [U]saves[/U] time. I still get a "bad" residue here and there, with the probabilities well known here around (due to the fact that I overclock a bit, etc), it is not that I have some "infallible" machines, the machines are normal, getting normal failure rates. Just that the bad residue is rechecked immediately when the mismatch happens, in both cards, saving a lot of time (only the time spent since the last checkpoint is lost).

Anyhow, I will be away from March 20 to April 20, therefore I am struggling now to finish all my assignments (except for R66, R967, and M666666667 which will be continued after). I only have now 3 FtLL in 67M, 68M, and 75M range respectively, to be concluded in the next ~50 hours.

The clLucas [URL="http://www.mersenne.org/report_exponent/?exp_lo=68721167&full=1"]currently running[/URL] will be the last, for a while. I will retire this card (and the system) from GIMPS, momentarily having better things to do with it, but also pissed off by the fact that clLucas's performance is "cheating", the time per iteration is not calculated properly, for example it shows 2.5ms/iterations when the real wall-clock-time is 11ms per iteration. Not few percents off, but 5 times off :rant:

Msft has to fix that. The problem is easier to see when different values are given to -c switch, the iteration time changes when it should not. This also reflect in James' tables (we salute the effort of introducing AMD cards in [URL="http://www.mersenne.ca/cudalucas.php"]that table[/URL]!) where for example a 7970 looks better than a 580, when in fact it is not. At least, not until clFFT libraries will be as fast as cuda counterparts. For example, my 580s are doing 6.2ms/iter for the same range of the expos, which means that either I am doing something extremely wrong, or the 7970 is half as fast as the 580.

[QUOTE=cuBerBruce;429314]
Edit: I've suspended work on M54627319 to wait and see if LaurV gets a match, and started working on M55415323 instead. As far as I can tell, nobody else is working on that one.[/QUOTE]
Match. Please cancel. Sorry for the trouble caused. (I don't feel guilty, you should read the thread :razz: hehe well, joking apart, I really forgot to reserve the two on PrimeNet, that is why all the fuss).

[QUOTE=LaurV;429426]Match. Please cancel. Sorry for the trouble caused. (I don't feel guilty, you should read the thread :razz: hehe well, joking apart, I really forgot to reserve the two on PrimeNet, that is why all the fuss).[/QUOTE]

I've removed it from my queue. The exponent status report shows it still being assigned to me, but it doesn't show on my assignments page. I guess I'll just leave things as they are and Primenet should eventually list it as expired.

Just to be clear, it is not my intention to take work that someone else claims via a post in this thread, even if they don't make a Primenet reservation. When MadPoo posts a new list, I guess I tend to assume it's free of exponents already claimed by someone. Anyway, I ended up doing 29% of a test for nothing - not that big of a deal to me.

I took these.
[CODE]55842821 2 1 4 0 4 0 DoubleCheck=55842821,73,1
55842847 2 1 4 0 4 0 DoubleCheck=55842847,73,1
55842889 2 1 4 0 4 0 DoubleCheck=55842889,73,1
56294479 3 0 4 0 4 0 DoubleCheck=56294479,73,1
56309111 3 0 4 0 4 0 DoubleCheck=56309111,73,1
59136463 7 2 1 2 1 2 DoubleCheck=59136463,73,1
67231393 2 1 1 0 1 0 DoubleCheck=67231393,74,1
70203857 2 0 1 2 3 0 DoubleCheck=70203857,74,1
[/CODE]

[QUOTE=Madpoo;428742][CODE]exponent Bad Good Unk Sus Solo Mis worktodo
55415323 3 1 1 0 1 0 DoubleCheck=55415323,74,1
[/CODE][/QUOTE]

I got a mismatch on M55415323.

I calculate there are a total of 51,220 primes up to nine digits long that contain all of the digits 1-5, and none of the other digits.