Trippple Checks

[Madpoo]

Originally Posted by Madpoo

...I also picked one of theirs that was verified (not by them) and I'm still waiting on my triple-check of that...

It just finished, no problems with it:
http://www.mersenne.org/M33390859

[Madpoo]

Originally Posted by Prime95

...At this point we have a mystery. The user was capable of building his own executable. Perhaps he did so with M39988591 and something went awry. We may never know.

Hopefully it's as innocuous as that. For my own peace of mind I'll triple-check the other 8 verified results from that user. Won't take long. I'm sure most of them are fine since the one from Kali was done first.

I'll also do a verifying run on the other 13 exponents where Kali's results are still unverified. I'd already added the first 5 into the hopper, just need to tackle 8 more.

Good thing this user didn't have a lot of LL results under their belt. Would have sucked big time if this were a more prolific tester.

[Madpoo]

Originally Posted by chalsall

Just for fun, I've thrown this on one of my "barbies". Should be done in about 24 hours.

I saw yours checked in, matching mine. Thanks for doing that.

Well, I guess whenever someone questions my Quixotic triple-checking adventure I can point to this as some kind of vindication. LOL

[henryzz]

Has he done any other tests that are worth checking?

[Madpoo]

Originally Posted by henryzz

Has he done any other tests that are worth checking?

I'm about done double checking his unverified results. They've all come up fine except one, I think, where the "Kali" result was bad but someone else had a residue already that I matched.

I'm also triple-checking his already verified results, although I don't expect to find any problems with those.

[Madpoo]

Originally Posted by Madpoo

Here's an updated list of the triple-checks to be done. 325 left.

I went ahead and bit off the last remaining ranges of work. I'm estimating being done with all of them in the next couple weeks, except M383838383 still has 22 days to go.

There'll be a few new ones sprouting up from time to time which I'll try to find and take care off here and there.

Well, I'd be further along but I keep adding new larger exponents to my to-do list to run first.

Some of them are kind of annoying, like:
M58496237

Maybe the user "accidentally" ran this on 2 different machines although they only had the one assignment.

Unfortunately the double-check was assigned to someone else just after the first-time check, so that user ended up poaching someone else's DC... someone who is actively crunching away on it.

In fact, for that one I don't really need to do my own triple-check because that person assigned the DC might finish theirs and save me the trouble. They're at 28.2 % as of just a little bit ago when they checked in. I guess I'll see if they finish and if not I can do my own TC then.

But anyway... there's still a few new ones showing up in the larger (60M-70M) range but I hope those will peter out.

[Madpoo]

Originally Posted by Madpoo

But anyway... there's still a few new ones showing up in the larger (60M-70M) range but I hope those will peter out.

By the way, I think I've figured out why Curtis is checking in a lot of self-verified stuff.

A) Curtis' team does a LOT of work, so the odds in favor of this happening are higher
B) Some of those systems are slow... like real slow
C) Those slow systems are having their assignments expired before completion
D) The exponent is reassigned and happens to be picked up by another Curtis machine
E) The original assignment keeps chuggin' along and finally finishes... sometimes before the new machine, sometimes after

So there you have it. I think maybe some of those slow Curtis machines might need to be looked at to see if there's a reason they're still getting assignments in the 60M range? Or maybe with 1st time checks taking longer as they get larger, the expiration rules might need to be lengthened a bit?

Right now there are 3 more Curtis assignments that are probably going to end up the same way... original one expired and was reassigned by chance to another Curtis machine, but the original one is still running and checking in:
65762689, 66991823, and 65282401

It may just be the last 2...the first one hasn't checked in for 30 days but the other 2 have checked in recently (yesterday or today).

[chalsall]

Originally Posted by Madpoo

Or maybe with 1st time checks taking longer as they get larger, the expiration rules might need to be lengthened a bit?

Another option: Primenet doesn't assign a candidate to the same Worker which it has previously expired.

[Dubslow]

Originally Posted by chalsall

Another option: Primenet doesn't assign a candidate to the same Worker which it has previously expired.

I think in this case Occam's razor is the best solution here.

[Madpoo]

Originally Posted by chalsall

Another option: Primenet doesn't assign a candidate to the same Worker which it has previously expired.

I certainly wouldn't trust a user who let an assignment expire get that same thing back again (at least in most cases). Certainly the large team accounts like Curtis have a huge variety of machines doing work, some fast, some slow. But still, I think it's fair to say "give someone else a chance" in any circumstance.

[endless mike]

Originally Posted by Madpoo

Anyway, if you wanted to do a verification of 60027139 for me, I'll do a check on 72316429 for you. I mean, I'll do that check of 72316429 anyway, you don't owe me anything.

Originally Posted by endless mike

Added to my worktodo.txt. Looks like two weeks to finish.

And verified http://www.mersenne.org/report_expon...0027139&full=1

I was a bit freaked out doing it, as Priment gave me an error when Prime95 would try to send estimated completion dates. I got "no assignment generated, reduntant LL effort" or something to that effect. In the end, Primenet accepted my result and I got credit. It also served as a nice doublecheck for my overclocked i5 4690k.