Strategic Double Clicking

[sdbardwick]

Originally Posted by cuBerBruce

The residue I got for this one did not match.

Ok, I'll run the TC on M34902599.

[LookAS]

I'd welcome TC these exponents:

M44110853, M48077509, M49134083, M49504331

[chalsall]

Originally Posted by cuBerBruce

The residue I got for this one did not match.

The lowest six of my runs from this batch have now completed; three matched, three didn't.

[chalsall]

Originally Posted by LookAS

I'd welcome TC these exponents:

I took them. Check them in ~60 hours.

[cuBerBruce]

Originally Posted by UBR47K

Requesting DC on:
...
Doublecheck=N/A,58475341,75,1
Doublecheck=N/A,58491773,75,1
...

I'm doing these two.

[Madpoo]

Originally Posted by lycorn

@Madpoo,
I´ve noticed a fair amount of 2M exponents that have been very recently triple checked by you. As the previous runs were matching, and they appear legit, I´m curious about the criteria used to select those ones for TC.

Just the fact that they hadn't been triple-checked already.

Similar to how I did triple checks of everything below 2M. No real purpose to it except just to confirm that earlier versions and newer versions of the software agree.

In this case, I don't really plan on doing all of the 2M-3M range, but I picked out the first 112 so I could do a test with my 28-core box. I set it up with 28 workers on one core each with 4 assignments, and let 'er rip.

Sad news there was that having 14 cores on the same CPU, even the small ones (which is why I picked these little 2M guys) was pretty lousy. When running a single worker it did something like 0.35 ms per iteration, but if all the cores were going it jumped to around 0.45 ms / iter.

I experimented with varying amounts of workers and cores-per-worker and just settled on 2 cores per worker which had per iteration times of something like 0.22 ms. Essentially no different throughput than having them all going with one core each, but oh well.

I let them finish out the 112 assignments and called it good.

[LaurV]

One of the three 59M's which I took, just ended with a mismatch. Free to be taken, I won't triple check it.
The other two still going for a couple of hours.
I was curious if doing this activity increases my number of "bad results". In which case I won't report the other if they mismatches. It seems like not, the exponent appears in my "unverified" list, and not in the "bat LL" list, which is ok. Point scored for the server this time...
(I looked into that because in the past there was a bug where the mismatched result was recorded as bad, and if someone TC and proves your result good and the older bad, then your "bad LL" list wasn't amended, retaining the "wrong" "bad result" for you - it seems like that bug is solved now).

[lycorn]

Originally Posted by Madpoo

No real purpose to it except just to confirm that earlier versions and newer versions of the software agree.

Fair enough. Thx for answering.

[chalsall]

Originally Posted by Madpoo

Okay, here's a list of exponents where the system had more bad than good but need add'l TF work to get up to GPU72 goals.

OK, so you know Aaron, most of these suspect candidates which needed additional TF'ing have now completed. There are still 40 to go at the moment -- these should trickle in in the next few days -- but this gives you a couple of hundred to offer for SDC'ing.

Tangentially... might it make sense to have a page on Primenet which your algorithm(s) list as desirous of a SDC? Not necessarily linked anywhere from Primenet itself, but posted here. This would allow those of us interested in helping out to request such candidates (by placing them in our worktodo files and ensuring we get a valid AID before proceeding) without bothering you to post additional candidates to be worked.

Just a thought.

[sdbardwick]

Originally Posted by cuBerBruce

The residue I got for this one did not match.

We match.

[Madpoo]

Originally Posted by LaurV

... Free to be taken, I won't triple check it.

Good... I'm already doing triple-checks on 3 more of your self-verified work.

You may have noticed that I picked up a bunch of your older results and did a double-check for you, free of charge. LOL

Originally Posted by LaurV

I was curious if doing this activity increases my number of "bad results". In which case I won't report the other if they mismatches. It seems like not, the exponent appears in my "unverified" list, and not in the "bat LL" list, which is ok. Point scored for the server this time...

Not sure how it used to work, but right now a mismatch will keep both of them set as "unverified" just like it was a first time check.

The only other thing that *could* happen is being marked "suspect" if it had certain errors along the way, but even then it's not marked as bad or anything until it's either verified for better or worse.

In a looser sense, I mentioned before that when I'm looking for potentially bad systems, in cases like this where there's a mismatch, I look at the total history of both systems and if one of them has been consistently good, I assume the other one is bad (just for purposes of my analysis of course, not actually marking the other result bad in the DB or anything).

In this particular instance for exponent M59662607, your system (for 2015) has a track record of 14 good, zero bad. Thumbs up. The other one has 1 good and 5 bad... 2 suspect results and 3 total mismatches. Ouch... thumbs down.

I still use my own rule of requiring 40 good and zero bad before I assume a machine that contributed one result of a mismatched set is the correct one. I should probably loosen that up to 10 good, zero bad and see what kind of newly "bad" machines I might find. And now that I only count a machine's results for a single calendar year, it's a little harder for some to meet that 40 result threshold... hmm... Yeah, I should figure out what constitutes a "reliable" machine, or maybe include *all* of the years for that system, not just one year.