From:                   Lucas Wiman  <[EMAIL PROTECTED]>
Subject:                RE: Mersenne: Multiple residues - enhancing double-checking
Date sent:              Wed, 4 Aug 1999 03:26:48 -0400 (EDT)


> True, but if the system is malfunctioning then the errors should start
> early.

        If the program is buggy, too. (v17 ghost is here)

> > Just for example, every 10% along the way, it'll send it's current residue
> > to the Primenet server.
> 
> I'm guessing that you mean a certain amount of the residue.  Sending in
> 10 2meg files for *each* exponent in the 20,000,000 range would get very
> unwieldy, and inconvenient for people and primenet.

        Aaron has said the same as me, using better grammar :-) . 
Obviously, only a few bytes are needed.

> Of course, this would only help if we were running more one test for the
> same exponent at the same time [...]

        The simultaneous checks are interesting only on the first 
stages of v19 or other "new" testers. When a complete double 
check will last 6 months in a new FFT size, while the author waits 
for a result, a lot of people will be using it. 

[...]
>  That is to say when
> one computer finishes to X%, it reports its 64-bit residue to primenet, and
> waits for the second computer working on the same LL test to do the same.
> Until the other (slower) computer reports in, the (faster) computer works on
> another exponent.

        Not at all. The first-time check goes its way, but reporting 
partial residues to coordinator / primenet from time to time. Later, 
often when first LLTest was finished long time ago, somebody 
receives:

Double-Check: 
M23780981,64,863FF87,678676AA,FF637BC,[...],CRC:9923FDA.

The partial residues corresponds to X iterations first, 2*X iterations 
second, etc. X is fixed for all participants. Or use percentages 
instead, as Aaron said. An absence of a residue between two 
colons means that is unknown. With a so long and sensitive data 
streams (200 bytes typical) the CRC is a must to detect accidental 
modifications of the Worktodo file.

        This schema makes possible simultaneous checking, 
though. But the start-stop mechanism you describe has little 
sense.

> This would speed up the entire project, but it would slow down the individual
> exponent, which would make people mad :(.

        My schema only would speed double checking. The first-
time LLTest process is untouched, except of the reporting of 
intermediate partial residues.


> As I pointed out above, the error rate should increase with the square of the
> exponent (plus change).  This means that if 1% have errors at 7mil, 22% will
> have errors at 30mil.

        That's the matter with the idea: an estimate of time saved 
(on double checking!) should be made. The authors of tester apps 
should estimate the early bug catching features of this schema, 
too. Then, decide if its worth or not.

        I'm doing double checking. I think about my computer 
running for 6 months when the error is on the second week. Argh!

        Saludos
                Oscar Fuentes.

P.D.: I promise to improve my English ;-)

_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

Reply via email to