Ken Kriesel writes:
>Participants in this phase of the QA should be willing to coordinate by
email with
>a partner, running LLtests and double-checks of the same exponent in
parallel,
>and cc George Woltman and myself, interim residues at suitable intervals.
Since you say you also want some non-Intel CPUs to participate her,
I have a couple of comments. An easier way to maintain a running check
of residues is to have the program write a simple Res64 (lower 64 bits
of the residue, in hex form) to a file every few thousand iterations.
Pair up users according to their hardware speed, i.e. so both members
of a QA duo are dispatching iterations for their exponents at roughly
the same speed. Save copies of full-length residue files only every
million iterations or so. If the Res64s for given iteration
match (which needs only a quick exchange of e-mail, once a week or so),
then the full-length files for iterations up to that point don't need to
be compared.
Jason Papadopoulos and I used this approach while testing F24, and it
proved quite convenient. We also did a diff of the final residue of
our respective runs, but had agreed beforehand on a common, platform-
independent savefile format. That is not the case for Prime95 and, e.g.
Mlucas, which is one more reason to use Res64s for at least the on-the-
fly crosschecking (the Mersenne, not hockey, variety :)
Also note that Mlucas starts its iteration counter at 1 rather than 0,
so when Mlucas writes (say) a 2000th-iteration Res64 to the .stat file
for a given exponent, it corresponds to the 1999th-iteration residue
of Prime95. Unfortunately that unit-offset dumbness on my part won't
be fixed until Mlucas 3.0 comes out, because I don't want to deal
with the logistics of figuring out whether a v2.7 savefile was written
by a unit or zer-offset version of the code and figuring out whether
an extra iteration needs to be tacked on before writing the next save-
file. (Mlucas 3.0 savefiles will have a different format, so that won't
be a problem.)
I can easily create a modified QA-only version of the 2.7 code to
use a zero-offset iteration counter, but want to make sure that this
will be part of an agreed-on QA scheme before doing so. George, can
you modify your code to create a QA version that writes periodic
Res64s to a file?
As for which non-x86 hardware would be suitable, here are some
estimated runtime estimates for testing an exponet in various
sample size ranges on the higher-end Alpha, MIPS and Sparc boxes
(all times in CPU-days):
CPU type/cache size: p~20M p~39M p~77M
-------------------- ----- ----- -----
500MHz Alpha 21264 83d 388d 1782d
64kB L1
4MB L2
400MHz Sparc E450 150d 677d 2763d
32kB L1
4MB L2
300MHz MIPS R12000 137d 609d 2524d
32kB L1
4MB L2
So, it doesn't look like testing exponents above ~40M is going to
be practicable any time soon, where I mean doable in a year or less.
But since the vast majority of GIMPS first-time LL tests won't even
be approaching 20M for some years yet, having one or two double-checked
exponents in each subrange below 39M would seem sufficient for the next
couple of years.
As a lure to prospective QA testers, I say they should be GUARANTEED
p90-CPU-years credit for whatever work they do, assuming they provide
a savefile useable by someone else with compatible hardware if they
choose to drop out before completing an exponent. Requiring them to
complete a really big exponent doesn't allow for all the kinds of
things that can occur during the several years it will take to do
some of these. As long as volunteer Y can pick up where volunteer X
left off, X should get credit for the cycles they contributed.
Cheers,
-Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
