processed dc and tc posts

[kruoli]

Originally Posted by Runtime Error

...
DoubleCheck=88828589,76,1	<--- someone did this one already
...

You yourself are listed as the triplechecker.

Originally Posted by Runtime Error

Edit: I'm running them as PRP-VDF instead of LL, but they are reserved as LL-DC. Thanks!

At least for the non-anonymous first or second time LLs, it would be nice to do the TC with LL, too. This is the only way a non-anonymous user can now if his machine was having an oopsie or the other machine.
Of course, no one will/can force you.

[Runtime Error]

Originally Posted by kruoli

At least for the non-anonymous first or second time LLs, it would be nice to do the TC with LL, too. This is the only way a non-anonymous user can now if his machine was having an oopsie or the other machine.

Yeah, perhaps this needs to be discussed more. UNC Willy had split off another thread that began with me asking about recommended DC protocol, but it devolved into a discussion about server-pushed updates. (Perhaps our exchange will be relocated there.)

If the goal is to "clear the deck" of double checks, then PRP-VDF is the way to go. From above:

Originally Posted by ATH

Yes, Suspect tests should be run with PRP VDF.
If there is 1 Suspect and 1 Unverified LL I guess if the person really wants they can run LL DC because in most cases probably >95% it will match the non-suspect, but PRP-VDF preferred.

If a known forumite is actively trying to diagnose hardware issues, then I am happy to help with a LL-DC, provided that someone else is just as willing to run another test. But PRP has been out for over a year & everyone should have switched by now. At this point, it would hopefully be finding errors that have already been fixed.

[kruoli]

You are correct. I skipped the fact that those were exponents with one suspect result. In that case, my reasoning from above weighs in much less.

[danc2]

Thanks RTE and Uncwilly. I was mostly thinking about the Ghz days that I erroneously have on my account, but I suppose its not a huge deal in my/my team's ranking.

BTW, PrimeNet is the server. Prime95, mprime, CUDALucas, etc. are the programs.

Oops, yes, I should have specified the primenet I was speaking about was a modified version of Loarer's new primenet.py for MLucas.

[DrobinsonPE]

I took DoubleCheck=83593817,76,1

[ChZ]

Requesting triple-check:

DoubleCheck=56939669,75,1

[Jan S]

@ChZ: I took.

[moebius]

Originally Posted by S485122

Says who ?

All 32 DC's that I have done recently have been C-LL - Verified

Is this effort now worthless for the project?

[kruoli]

No, as soon as the LL run has a verified "brother/sister", we have reached our main goal for that exponent - we have a correct primality result for this exponent with absurdly high probability. There is a mathematical chance of error, but is extremely, extremely small.

[Uncwilly]

Originally Posted by moebius

All 32 DC's that I have done recently have been C-LL - Verified

Is this effort now worthless for the project?

Past LL's that have been verified are of value. When we have a match of 2 LL runs, we now that status of that number with great certainty.

If there are 2 LL runs that mismatch and we have no reason to think that a particular one of those is flawed (one or both may be, but sometimes small errors happen at random), a 3rd LL test should quite reasonably decide which is correct.

If there are 2 LL runs that mismatch and we have a reason to think that a particular one of those is flawed, then there is a higher chance that a 4th check will be needed. With the Gerbicz error checking available in the PRP tests, the chance that an error gets through is very low. And now we have the added benefit of the VDF certification process. Putting these in effect tips the expected total cycles invested in proving a number not prime in favour of running a PRP w/cert on exponents with a suspect result and an LL that is not matching. (Not for any single exponent, but as a whole. The number that would require a quad check LL are enough to tip the scale.)

[moebius]

I performed this DC'S because the FFT size makes it the optimal work for the Ryzen 3700X and Vega64 in terms of GHz / Days.

99% reliable with Win Pro 10 ,Ryzen 3700X ans Prime95.29.8b6 and Asus ROC Vega 64 mining and gpuowl v6.11-292 .

unfortunately no double checks in the 53 / 54M area CPU / GPU are available.