[QUOTE=srow7;438672]could use a TC
I have already done a TC on a different machine on the side.
Mine is correct.
Thanks

41937001 LL Unverified;2009-06-27;-Anonymous-;8DB80F8E430E75__
41937001 LL Unverified;2016-06-03;srow7;D88C505E833AE8__[/QUOTE]

Queued. Should be done by Friday.

Got 2 unverified DC's a couple months ago....
 

78409057
78409361

Both previously tested by Robert_SoCal

[QUOTE=petrw1;438843]78409057
78409361

Both previously tested by Robert_SoCal[/QUOTE]

Added to my worktodo

[QUOTE=petrw1;438843]78409057
78409361

Both previously tested by Robert_SoCal[/QUOTE]

The pile of these is getting a lot higher than two, the last big batch Madpoo and I did had dozens. Sad since this user is such a large contributor, with such unreliable resources.

[QUOTE=airsquirrels;438864]The pile of these is getting a lot higher than two, the last big batch Madpoo and I did had dozens. Sad since this user is such a large contributor, with such unreliable resources.[/QUOTE]

Yeah, I did at least 4 of those, too.

[QUOTE=airsquirrels;438864]The pile of these is getting a lot higher than two, the last big batch Madpoo and I did had dozens. Sad since this user is such a large contributor, with such unreliable resources.[/QUOTE]

His current lifetime status for that machine (or rather, collection of machines, I'd guess, but they all report under a single cpu ID) is:

Good = 82
Bad = 182
Mismatches = 2
Unknown = 504

The "bad" results include guesses where someone with a better track record did a mismatching DC. The 2 listed as actual mismatches must have been cases of the other tester not having enough track record to make the same assumption, but I think we could reasonably say those probably belong in the bad category as well.

With such a large pool, it's actually better to track it by year/month because his machine(s) seem to go through definite periods of goodness and badness.

From the below, you can see how it stands now, and see that there are still periods of time where no good data exists to say if it was trending one way or the other.

[CODE]YYYY-MM Good Bad Mis Solo
2012-11 5 5 0 1
2012-12 11 0 0 0
2013-1 3 2 0 0
2013-2 1 0 0 4
2013-3 1 2 0 2
2013-4 1 0 0 3
2013-5 1 0 0 0
2013-6 1 0 0 3
2013-7 0 5 0 0
2013-8 0 2 0 4
2013-9 0 2 0 1
2013-10 1 2 0 2
2013-11 0 2 0 2
2013-12 1 0 0 5
2014-1 2 0 0 4
2014-2 1 0 0 2
2014-3 0 3 0 1
2014-4 0 2 0 1
2014-5 1 0 0 7
2014-6 2 6 0 0
2014-7 2 0 0 10
2014-8 1 0 0 12
2014-9 3 14 0 0
2014-10 3 9 0 0
2014-11 1 22 0 1
2014-12 3 22 0 5
2015-1 3 29 0 7
2015-2 4 25 2 0
2015-3 6 24 0 4
2015-4 2 1 0 24
2015-5 2 0 0 26
2015-6 3 0 0 33
2015-7 4 0 0 26
2015-8 5 0 0 34
2015-9 1 0 0 38
2015-10 1 0 0 37
2015-11 2 0 0 32
2015-12 1 0 0 32
2016-1 2 0 0 25
2016-2 1 0 0 13
2016-3 1 0 0 21
2016-4 0 0 0 23
2016-5 0 0 0 20
2016-6 1 0 0 21
2016-7 1 0 0 18[/CODE]

[QUOTE=petrw1;438843]78409057
78409361

Both previously tested by Robert_SoCal[/QUOTE]

[QUOTE=endless mike;438856]Added to my worktodo[/QUOTE]

Completed and matched your results for both. Two more for the bad pile for Robert_SoCal.

[QUOTE=Madpoo;438077]Gah... I don't know what happened, but lately Curtis' account has been churning out a lot of self-verified work. It looks like some old assignments expired and got reassigned to another of his computers, and then the original machines got turned back on and are continuing the work, but as a double-check now.

Or... They're all in the 67M range which makes me think they're being expired quicker under the new rules and probably shouldn't have been assigned to those slower machines in the first place.

The assignment rules won't give out an assignment to the same person who did the first check, but there's nothing preventing a user from getting a new assignment on something they already had, but expired. That's probably fine most of the time, but not right now.

Maybe once the new expiration rules have settled into place and all these expirations of stuff assigned under the old rules has worked through, it won't be an issue...

There are about 5 or 6 right now, plus I count another 32 or so that are probably going to finish up soon as more self-verified work.

I've been keeping up with the periodic entries that show up here and there, but is there anyone interested in doing independent checks on these?

Here's what needs independent checks currently:
[CODE]DoubleCheck=67588013,75,1
DoubleCheck=67657747,75,1
DoubleCheck=67665629,75,1
DoubleCheck=73309741,75,1
DoubleCheck=73312229,75,1
DoubleCheck=92408501,75,0[/CODE][/QUOTE]

[QUOTE=endless mike;438252]Looks like no one else has spoken up to claim these, so I've added them to my worktodo lists.[/QUOTE]

These all now have an independent triple check done.

[QUOTE=endless mike;439400]These all now have an independent triple check done.[/QUOTE]

Awesome! Thanks for helping on those.

I'm not sure how it happened, perhaps just a weird side-effect of the new expiration rules, but Curtis' computers had a bunch of assignments in the new cat 0/1 ranges that expired, but then other machines of his picked up the new assignment. As a result, he ended up doing a first-time check, but the old machine was still running and turned in their result as a double-check.

There were also a strange (and totally not sure how it happened) surge in "anonymous" users getting assigned DC's for exponents where another anon-user did the first check. That one is weird because there was already something there to keep that from happening, but there they are...

I introduced a new assignment clause to keep someone from being assigned work for the same exponent they let expire recently and may in fact still be working on. It won't prevent you from getting an assignment that expired several months ago and you haven't checked anything in lately, so it shouldn't permanently block anyone from ever working on that same #. I call it the "curtis clause" just because his systems were the ones I saw the most falling into that pattern, simply because of the # of machines involved making it more likely, but it did happen on a handful of other users by chance.

Anyway, all of the new ones I should be able to keep up with but it was great to have some help on those.

Hi All,

Not sure if this is the right area for this, but one of my new machines has just returned a result of C - Mismatch. (exponent was 42576029). I'm assuming this means that I've returned a different residue than the previous LL assignment.

I'm curious as to what happens now.

Cheers,
Chris.

May I get someone to triple-check 38849663? My GTX1080 has been reliable so far so I suspect this is someone else's poorly-working machine eight and a half years ago.