At 06:07 PM 3/6/2000 EST, you <[EMAIL PROTECTED]> wrote:
>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 here,
>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.
What I meant was interim 64-bit residues (not full intermediate savefiles
or full-length residues) every 1 or 2 million iterations, since they will be
compared visually. QAtest volunteers are typically being partnered, and
exchanging just the 64-bit residues by email & cc myself &/or George.
(Keeps the email size much smaller than passing save files, and removes
the temptation of cheating.)
There's no point in the larger traffic of a 64-bit residue every few
thousand iterations, which corresponds to an hour or two of runtime at most.
The QA volunteers are encouraged to keep the full-length intermediate files
of
every million or two million iterations intervals, and do backups, and if
quitting,
transfer the last good save file so someone else can take up where they
leave off.
...
>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?
That modification is already present in prime95.
Output looks like this:
[Sun Feb 13 16:51:26 2000]
M4948673 interim residue 06B0A8372B7C3239 at iteration 2000000
[Thu Feb 24 23:45:20 2000]
M4948673 interim residue 7D4B80BF1E9DF827 at iteration 4000000
Lots of results (verified by 2 independent runs on separate processor
generations in V19 prime95) were available at iteration counts of 100 and
400 if I recall correctly, partly for validating future programs, at
ftp://lettuce.edsc.ulst.ac.uk/gimps/PrimeQA/QADATA.TXT
thanks to Brian Beesley for generating the list of exponents to run on,
running most or all of one pass, and hosting the data.
I see that file's no longer there.
The intent of this part of the QA effort was to provide validation of
iteration code on many exponents quickly, both for QA of prime 95 V19,
and future versions of various programs, including the less fast ones,
in all ranges of exponents and runlengths prime95 currently supports.
>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.
Remember the 10-mega-digit hunters; there will be exponents above
p=33,000,000 tested before long. Some already have 10M or 12M iterations
done.
QAtesters may play the same hardware-upgrade game as the rank & file,
and upgrading hardware more than once before completing the truly large
exponents is likely. (Last year's fast system was a PII-400; it would take
6.5 years to do p=79,299,xxx; who wants to keep the same workstation
for 6 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.
I'd like to see them get cpu credit, but I am not in a position to
guarantee it.
Most of the effort would fall on someone else, and I'd rather see George
and Scott doing other things than the bookkeeping of apportioning credit
by iteration count and exponent size and checks of usable save
files. To keep the minimum contribution sizable, I ask the volunteers to
commit to at least a half-PII-400-year; large contributions are more likely
to justify crediting the work or a partial large exponent.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
