Strategic Double Clicking

[Madpoo]

Originally Posted by chalsall

Interestingly, all but one (35196527) _matched_.

Hmm... might not be as interesting as I'd hoped. Well, thanks for checking those. When I get some worktodo's cleared out I'll do some more experimenting of my own. I really thought I was on to something, but it may need some fine tuning, and it depended on that client version as a basic measure of reliability during certain time windows which would be a rough approximation at best.

[Prime95]

Instead of program version, why not use the year the LL result was submitted. MS-SQL should be able to do a GROUP BY on that fairly efficiently. This has the advantage of catching machines that did not update the prime95 application.

I know you mentioned something like this earlier. I would give it a try before giving up on it as too burdensome for the server.

[Madpoo]

Originally Posted by Prime95

Instead of program version, why not use the year the LL result was submitted. MS-SQL should be able to do a GROUP BY on that fairly efficiently. This has the advantage of catching machines that did not update the prime95 application.

I know you mentioned something like this earlier. I would give it a try before giving up on it as too burdensome for the server.

That would probably be okay. I had in mind a grander thing like a rolling 1-year average, not necessarily tied to any given calendar year, but I know from my day job that doing things like that can be pretty taxing, even if it is more accurate.

Still, I can give that a shot. All it takes is doing a datepart, more or less, on the received date for the result. What the hey, I'll try that later.

[chalsall]

Originally Posted by Madpoo

Still, I can give that a shot. All it takes is doing a datepart, more or less, on the received date for the result. What the hey, I'll try that later.

Feel free to throw a few experimental tests my way. I don't have your firepower, but I can do 10 or so a day in the lower ranges.

[endless mike]

Earlier today I finished the last of the double checks that I had most recently claimed in this thread. All but one matched with the first time test.
50398199 Matched first test
52040731 Did not match first test
52405957 Matched first test
52939417 Matched first test
53562269 Matched first test
54170447 Matched first test
56868607 Matched first test

[dragonbud20]

M47921893 needs a triple check

[Madpoo]

Originally Posted by dragonbud20

M47921893 needs a triple check

That looks like one of the weird ones where the previous tester had their result checked in twice by mistake:
http://www.mersenne.org/report_expon...7921893&full=1

I've been testing as many of those as I can. Usually I match, but I've had two now where my result was different, and yours makes a third one I'm aware of.

For me, I've just been assuming my result is correct. If your machine is stable enough then we can pretend the same for you until the double-checkers finally get up to the 47M range (could be a while).

I think I'd mentioned before that currently there are something like 4800-5000 exponents below 58M that have been DC'd without a match. *Most* of those are because one of them was suspect during it's first run, so the mismatch isn't terribly surprising.

For the other 940 where neither result was suspect (like this one), I might start taking on some of those, because it seems weirder when a machine returns a bad result without it being marked suspect. If we can identify those machines then we may have a good idea that other tests of theirs are wonky.

[chalsall]

Originally Posted by dragonbud20

M47921893 needs a triple check

I'll run it. Should take ~48 hours or so.

[cuBerBruce]

I have confirmed dragonbud20's residue for M46102687.

[Madpoo]

Originally Posted by Prime95

Instead of program version, why not use the year the LL result was submitted. MS-SQL should be able to do a GROUP BY on that fairly efficiently. This has the advantage of catching machines that did not update the prime95 application.

I know you mentioned something like this earlier. I would give it a try before giving up on it as too burdensome for the server.

Well, I tried it out, as far as generating some reports... next step would be to actually do some LL tests on exponents I've found using the breakdown-by-year method.

And now, here's an example of a specific CPU. In aggregate this machine looks pretty good:

Bad	Good	Sus	Unk	Solo	Mis
12	74	4	41	39	6

Only 12 bad out of 74 good, well hey, that's decent. I wouldn't have bothered looking at it any more...odds of finding more bad in those 39 solo-checked stuff would seem to be low.

But break their results down by year and we see an interesting pattern:

Year	Bad	Good	Sus	Unk	Solo	Mis
2008	0	9	0	2	2	0
2009	0	52	0	8	8	0
2010	1	12	0	26	24	2
2011	11	1	4	5	5	4

Seems like 2011 was a bad year for this system... 11 of the 12 known bad were from this year, and it only has 5 solo-checked exponents, so maybe it wouldn't be too bad to check those out.

In fact that's what I plan to do. I picked up all 5 of those (47M-49M range) so I'll know in a day.

If anyone else is interested in trying out a couple smaller ones using this approach, here's a few:

37952297	19	3	3	0	3	0	DoubleCheck=37952297,71,1
38155841	12	3	3	0	1	2	DoubleCheck=38155841,71,1
41720983	3	0	3	0	3	0	DoubleCheck=41720983,72,1
42676009	3	0	4	1	4	1	DoubleCheck=42676009,72,1
42846421	5	1	6	1	6	1	DoubleCheck=42846421,72,1
43100209	3	1	6	0	5	1	DoubleCheck=43100209,72,1
43268627	4	1	2	0	2	0	DoubleCheck=43268627,72,1

[LaurV]

Originally Posted by Madpoo

Seems like 2011 was a bad year for this system... 11 of the 12 known bad were from this year, and it only has 5 solo-checked exponents, so maybe it wouldn't be too bad to check those out.

Very nice report! This only reinforces again and again the fact that P95 is an extremely good "stress tester". I would recommend for all sysadmins to run it at least few hours per day in their networks, doing DC work . This guy's computer ran for years without much a problem, then it started producing junk, and at the end, got replaced. If he would pay attention earlier to the output, he had a very early indicator that his system went in the weeds, and we would have less headache now, too...