Trippple Checks

[Madpoo]

Originally Posted by Mark Rose

After seeing mprime's estimate, I'll grab these, too:

DoubleCheck=27229123,71,1
DoubleCheck=27251701,71,1
DoubleCheck=27251827,71,1
DoubleCheck=27284339,71,1

Everything should be done towards the end of June.

Awesome, you guys all rock! I've marked those sections out for y'all.

[Madpoo]

Originally Posted by Madpoo

Awesome, you guys all rock! I've marked those sections out for y'all.

Here's an updated list just to keep it clear.

By the way, I just put version 28.6 on all of my triple-checking systems. It added detection for the E5-xxxx v2 processors (Ivy Bridge) which may be just cosmetic, but I feel better seeing it detected as i3/i5/i7 rather than generic Intel.

And since I'm doing triple-checks anyway this will be a good way to just make sure I'm still matching the older results.

[Madpoo]

This was an "extra" in the regular triple-checks. The main ones are those "self verified" results which I'm assuming are all going to be okay, but warrant an extra, independent check just to make sure.

Here and there I've chased down a few other rabbit trails looking for oddities. One such thing was looking for exponents that already had multiple checks done, including with matching residues, but with the same shift count *and* submitted by different users.

For whatever reason, there are some users who apparently thought it a good idea to submit the same result over and over through different accounts. The server very smartly didn't count those extras as verifying runs, but they show up in the details. If the same user had submitted it over and over, the server would have ignored it entirely.

And here is one example I just found of why I'm glad I'm checking into those:
http://www.mersenne.org/M36742943

It would have eventually been assigned to someone as an actual double-check, but I still feel like something a little "iffy" was going on where someone submitted the same residue, same shift count, different users (one registered, a couple anonymous), years apart. Just seems strange to me.

I'm focusing on some of the most egregious cases, where the same residue/shift count shows up 3+ times, and also anything in the 37M and below range for now (just a dozen or so).

Anyway, just thought I'd share, even though this wasn't technically a triple-check. More of an unusually roundabout double-check.

EDIT: And by the way, it actually will need a triple-check since mine and the "mystery" results didn't match.

[Prime95]

Originally Posted by Madpoo

For whatever reason, there are some users who apparently thought it a good idea to submit the same result over and over through different accounts.

There was a version of prime95, under circumstances I was never able to figure out, that forgot the user id. When that happened the server would assign a new user id --- one of those Snnnnnn user ids. This explains the different user ids, but not why the test was run multiple times (and in your case starting from a save file after the computation error had occurred).

[Madpoo]

Originally Posted by Prime95

There was a version of prime95, under circumstances I was never able to figure out, that forgot the user id. When that happened the server would assign a new user id --- one of those Snnnnnn user ids. This explains the different user ids, but not why the test was run multiple times (and in your case starting from a save file after the computation error had occurred).

Weird. Yeah, there are a handful of extreme examples:
www.mersenne.org/M35716517
http://www.mersenne.org/M36290129
http://www.mersenne.org/M35976943

The common element in these extreme examples (4+ of the same result) seems to be that one actual, non-anon user. Must have been something going on there.

I can't remember now, but I think there were maybe 10-12 of them where there were 5 or 6, and I've cleared all but 2 now.

Some are already assigned out for double-checking... they'll all get checked again eventually so it's all good, I just thought it was fun to find these, and especially that one where their residue was (presumably) bad.

[LaurV]

We also got some of those, especially the second one is very interesting, it looks like different users who reported the same residue, were wrong, and another user did a successful verification of his own work, which is fishy, fortunately we knew about the P95 which was losing the user name.

[Madpoo]

Originally Posted by LaurV

We also got some of those, especially the second one is very interesting, it looks like different users who reported the same residue, were wrong, and another user did a successful verification of his own work, which is fishy, fortunately we knew about the P95 which was losing the user name.

I kind of wonder if some users thought they could resubmit results for whatever reason?

I just finished another one:
M34868497

The odd thing about that is that between the 2 repeat results was one from another user that had a different residue (which turned out to be the correct one).

I wondered if the original submitter saw the mismatch from their first run and just resubmitted the one they had? Beats me. I'm fond of saying that "People Are Weird"

[LaurV]

Yes, these all fail to DC because fortunately they have the same shift count. Therefore is not an intentional cheating, but the bad P95 version, as George said. A "cheater" would try to change the shift count (and then the checksum) too.

[Madpoo]

Originally Posted by LaurV

Yes, these all fail to DC because fortunately they have the same shift count. Therefore is not an intentional cheating, but the bad P95 version, as George said. A "cheater" would try to change the shift count (and then the checksum) too.

Agreed. I'm going to chalk that one up to user error, aka "a short between the keyboard and the chair"

[kladner]

Originally Posted by Madpoo

Agreed. I'm going to chalk that one up to user error, aka "a short between the keyboard and the chair"

AKA: "Loose nut behind keyboard."?

[Madpoo]

Here's the latest snapshot of things.

I'm reserving from 33M up. I think that will carry me through the next 30 days, plus the other work I'm doing to triple-check things where the same user did it multiple (3+) times.

Plus, I'm down to something like 45 days for that 383M exponent. Sure will be interesting to see how much faster CPU's can do an exponent like that in a few years time.

For now that leaves 27.29M - 28M, 28.5M - 29M and 32M - 33M up for grabs if anyone wants.