On 3 Feb 2001, at 17:03, Jeff Woods wrote:
> > >With increasing exponent size (and therefore run time), I'd like to
> > >see PrimeNet evolve to track intermediate residues & also to be able
> > >to coordinate parallel LL testing & double-checking, so that runs
> > >which are going wrong can be stopped for investigation without having
> > >to be run through to the end.
>
> I think this is an EXCELLENT idea, but remember that the "s" values (i.e.
> the intermediate residue/modulus) for such numbers is quite simply
> enormous. One couldn't (and shouldn't) check the entire intermediate
> value, but merely the last "x" bits, where "x" is enough to be reasonably
> certain that a match isn't random chance -- say, the final 1024 bits.
64 bits is enough to be pretty confident! We need a recovery
procedure anyway, to cope with any systematic bugs which may exist.
>
> PrimeNet would thus also have to carefully assign the exponents to similar
> machines with similar runtimes and performance, as it would do little good
> to assign the primary test to an Athlon-800 and the "real-time"
> double-check to a much slower machine, as the Athlon would quickly outpace
> the second check.
>
> If a discrepancy was found in a real-time double-check, a ternary run on a
> different machine could determine which (if either) of the two intermediate
> residuals was correct, and the tests could proceed from there, with both
> original machines assuming the same correct residue.
>
My reply to Ken Kriesel's message on this topic shows how the need
for paired systems to be evenly matched could be avoided - though it
is certainly preferable that gross mismatches are avoided. However,
there shouldn't be much problem providing reasonable matches, since
the PrimeNet server knows each participating system's CPU type &
clock speed.
> Also, if this did evolve, I'd suggest that the "double-checker" be given
> equal credit with the primary machine, for purposes of credit in history
> books as discoverers, and/or EFF monies.
This question obviously needs to be addressed, if only to keep
lawyers out of our hair. I agree with Jeff on this one.
>
> Note that there's a point of futility, at which a "tie-breaker" ought to
> merely be a triple-check, run to conclusion. Let's say on a 14-month co-op
> effort, 13.6 months into it a discrepancy was found. Both machines ought
> to finish, and just have it triple-checked, rather than suspending both,
> awaiting a tiebreaker. While I'm sure someone could solve for the optimum
> cutoff point where tiebreakers are not useful, my guess would be that it is
> around 85% of the way to completion.
With the suggestions in my reply to Ken, having "late" checkpoints
doesn't do much to slow down completion - the leading system proceeds
unless or until the trailing system finds a discrepancy. However, I
certainly agree that there's not much point in having a checkpoint at
iteration 14 million if you're testing e.g. exponent 14000003. I'd
suggest "missing out" the last checkpoint if the number of iterations
remaining at that point is less than half the iterations between
checkpoints.
Regards
Brian Beesley
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
