[QUOTE=chalsall;551896]Hey George. More data...

So, my Winblows machine has done two CERT runs in the last day. [URL="https://www.mersenne.org/report_exponent/?exp_lo=97265881&full=1"]97265881[/URL] matched, while [URL="https://www.mersenne.org/report_exponent/?exp_lo=97282747&full=1"]97282747[/URL] didn't (your run confirmed the original PRP run was good).

Neither of these went through the Proxy. Direct comms with Primenet.

Is it possible this new code path is exercising different part(s) of my kit, and I might need to service it? I /think/its history with DC'ing has been flawless.[/QUOTE]

CERT runs the exact same FFT code as DC'ing except the exponents are a bit larger. I need to get v30.2 released which properly MD5 checks the downloaded starting value.

[QUOTE=kriesel;551901]I
[URL]https://www.mersenne.org/report_top_500/[/URL] has no cert info
[URL]https://www.mersenne.org/report_top_500_custom/?type=0[/URL] has no stats type for certs
[URL]https://www.mersenne.org/report_top_teams/[/URL] has no cert info
[URL]https://www.mersenne.org/report_top_500_custom/?type=10000[/URL] has no stats type for certs[/quote]

CERTs are credited as PRP-DC or as PRP-cofactor-DC. I didn't see the need for yet another stats type.

[quote]
There is currently no manual CERT assignment, and that may be by design. [URL]https://www.mersenne.org/manual_assignment/[/URL].[/QUOTE]

I don't think CERTs will ever be available as manual assignments. CERTs are quick turnaround items. Manual users are often not quick.

Now gpuowl with python scripts feeding it is more like a prime95 setup than a manual user. I could see doing CERTs with gpuowl.

A sea change.
 

It occurred to me yesterday that there may soon come a point where people start thinking about discontinuing LL work to versions of prime95 < 30 because it would be almost as much work to DC their output as it is to check a new number.

Maybe they would be forced to do only doublechecks since they would basically be the only ones producing residues to DC in the first place.

And does the assignment code also prevent users from getting certs for their own PRP runs?

And as mentioned/noted previously all PRP's that are being handed out to V30 machines get a VDF generated, even if the PRP is a DC. Will these eventually get the certs run?

[QUOTE=Uncwilly;551934]And does the assignment code also prevent users from getting certs for their own PRP runs?[/quote]

No. You cannot game the system even knowing the full contents of the proof file.

[quote]And as mentioned/noted previously all PRP's that are being handed out to V30 machines get a VDF generated, even if the PRP is a DC. Will these eventually get the certs run?[/QUOTE]

Yes, ought to happen now though I did not test this.

[QUOTE=Prime95;551922]I could see doing CERTs with gpuowl.[/QUOTE]

Yes, GpuOwl processing CERTs would be possible, but is that necessary or useful? I think the whole supply of CERT work that we can expect in the future can be easily handled by mprime.

Also, CERTs being short tasks, they could be an ideal work type for new users that have the bad habit of being ephemeral. (CERTs could also be used for initial validation of new hardware instead of DCs). This way the amount of work lost because "user left half-way through the test" would be much lower.

And I expect new users to be more likely mprime users than GpuOwl users.

And now we see that one heavy-weight GpuOwl deployment doing CERTs would "destroy" the valuable limited supply of CERTs at an alarming rate :)

[QUOTE=Prime95;551951]
[QUOTE=Uncwilly;551934]And as mentioned/noted previously all PRP's that are being handed out to V30 machines get a VDF generated, even if the PRP is a DC. Will these eventually get the certs run?[/QUOTE]

Yes, ought to happen now though I did not test this.[/QUOTE]

Just in case someone is looking for an example, I recently turned in [M]87829211[/M] along with a proof file. The cert run hasn't been assigned yet. But the couple first time checks w/ proofs that I uploaded at the same time have all been run already and matched.

[QUOTE=Prime95;551918]CERT runs the exact same FFT code as DC'ing except the exponents are a bit larger. I need to get v30.2 released which properly MD5 checks the downloaded starting value.[/QUOTE]

CERTs could (and should?) use the same GEC as the normal PRP iterations. This way the correctness of the CERT work can be verified locally (that's what GEC does) before sending the CERT result.

Assuming the proof is good, we then have only three possibilities:
1. data corrupted during transfer -- detected through MD5 checksums
2. the CERT iterations have errors -- detected by GEC and fixed through rollback
3. something else is wrong (server-side/bug?)

[QUOTE=preda;551957]CERTs could (and should?) use the same GEC as the normal PRP iterations. This way the correctness of the CERT work can be verified locally (that's what GEC does) before sending the CERT result.

Assuming the proof is good, we then have only three possibilities:
1. data corrupted during transfer -- detected through MD5 checksums
2. the CERT iterations have errors -- detected by GEC and fixed through rollback
3. something else is wrong (server-side/bug?)[/QUOTE]

I did not implement GEC for CERT work. I did not think it was worth the bother. What I did implement was shift count. If one CERT fails another is run with a different shift count.

[QUOTE=Runtime Error;551956]Just in case someone is looking for an example, I recently turned in [M]87829211[/M] along with a proof file. The cert run hasn't been assigned yet. But the couple first time checks w/ proofs that I uploaded at the same time have all been run already and matched.[/QUOTE]

I'm attempting a fix now.

[QUOTE=Prime95;551960]I did not implement GEC for CERT work. I did not think it was worth the bother. What I did implement was shift count. If one CERT fails another is run with a different shift count.[/QUOTE]Some Certs will land on old hardware that may be less reliable, or proof files come from slow mini hardware after Mlucas adopts it; Odroid, RPi, smartphones, possibly at low proof power values, for which the verification will take longer.