processed dc and tc posts

[Jan S]

I took these:

DoubleCheck=56873423,74,1
DoubleCheck=57005393,74,1
DoubleCheck=57033289,74,1
DoubleCheck=57039707,74,1
DoubleCheck=57194437,74,1
DoubleCheck=57243961,74,1
DoubleCheck=57258979,74,1
DoubleCheck=57309079,74,1

[DrobinsonPE]

I finished the previous three and took these three.

Doublecheck=54346063,74,1
Doublecheck=54385493,74,1
Doublecheck=54494767,74,1

[Uncwilly]

Originally Posted by Viliam Furik

I took it. It's assigned on PrimeNet. Will do a PRP CERT test

It has been completed and Ben ran the cert.


The list has been updated.

[kriesel]

Reserved 55842469; P-1 running now. If NF, expect DC done Oct 2. ECC ram workstation prime95 V30.3b6.

[Uncwilly]

Originally Posted by kriesel

Reserved 55842469; P-1 running now. If NF, expect DC done Oct 2. ECC ram workstation prime95 V30.3b6.

[Runtime Error]

A few of the 88s are under work by some folks:
88540577
88535329
88514381
88476737

And I took these ones:
88457249
88470937
88475831
88494971
88503689
88504093

Is there a strong preference if they are run as PRP or LL? Krisel writes (edited):

Originally Posted by kriesel

It's worth thinking about the pros and cons.
Reliability data versus exponent on LL will show the effectiveness of the current error detection methods including Jacobi check.

The timeliness of a prompt GEC check or Cert is of much greater value in my opinion than LL reliability feedback on a computer that ran LL first test several years ago. Many of those systems that produced existing LLDC candidates' first tests (54M and higher) are likely to no longer be in operation or running primality tests by the time the LL reliability feedback is obtained, if not already replaced by now.

There is a very slight ~2% throughput advantage to PRP/GEC/CERT over LLDC, and a large reliability advantage. Approx 2% x 506K DC to Mp51 adds up (~10,120 tests).

Just checking if folks have strong feelings about it either way. If not, I'll run them as PRPs.

[Uncwilly]

Originally Posted by Runtime Error

And I took these ones:
88457249
88470937
88475831
88494971
88503689
88504093

Is there a strong preference if they are run as PRP or LL?

Since those have a suspect LL, our most efficient tests would be PRP. Unless someone asks for a test specifically (like has been done before in this thread), suspect LL's with a mismatch should get PRP.

Take 88476737 too, it has shown Zero progress in more than a year.

[Runtime Error]

Originally Posted by Uncwilly

Since those have a suspect LL, our most efficient tests would be PRP. Unless someone asks for a test specifically (like has been done before in this thread), suspect LL's with a mismatch should get PRP.

Take 88476737 too, it has shown Zero progress in more than a year.

Ok cool, thanks for the info. I'll have to come back for that one!

[phillipsjk]

Originally Posted by Uncwilly

Since those have a suspect LL, our most efficient tests would be PRP. Unless someone asks for a test specifically (like has been done before in this thread), suspect LL's with a mismatch should get PRP.

Take 88476737 too, it has shown Zero progress in more than a year.

One disadvantage of that strategy is that without a tie-breaker, my one machine is no longer considered reliable enough to do CERT work.


However, that can probably be handled by tweaking the criteria for CERT work if needed.


I don't strongly care either way, beyond the ego-boost of having a "reliable" computer.


Everyone I mentioned it to IRL were confused due to the lack of context.


"What's up?"


"One of my computers is now considered reliable enough to do certification work!"


"???"

[Uncwilly]

Originally Posted by phillipsjk

One disadvantage of that strategy is that without a tie-breaker, my one machine is no longer considered reliable enough to do CERT work.

The error checking code used in the PRP test will tell if your computer is reliable enough. It can even fix problems.

[phillipsjk]

Originally Posted by Uncwilly

The error checking code used in the PRP test will tell if your computer is reliable enough. It can even fix problems.

Valid point.



Currently doing "tie breaking" work for 4 months. Any needed QC's after that will probably convince me. ;)


I am also doing a single DC on another machine: timelines do not allow me to do it over as PRP and still meet deadlines (clock was eaten up by discarding 20% of first-run PRP work, but I was assigned LL doublecheck work while upgrading).


I NOW know you can just modify the "doublecheck" line to "PRP", add a few parameters, and the server will accept the result. But as was mentioned, there is some residual usefulness confirming past LL results.