> From this I understand that it takes around about the same number of
> interations as the size of the exponent to establish primality.
Correct. See the FAQ at the end of this message for more info.
> I've got several UltraSPARCs I've pressed into service and currently
> have 7 exponents check
> This scheme makes almost no sense for normal double checking.
> This is becuase
> it would save *no* time at all. Think about it, even if you
> identify that an
> error ocurred in the second week of a 3-month test, you still
> have to run it
> to completion, and a third test must also be run.
> I've got several UltraSPARCs I've pressed into service and currently
> have 7 exponents checked out being tested with MacLucasUNIX.
> It's doing fractionally more than one iteration every second. That's
> judging by the times between checkpoint files at 5000 iterations
> between checkpoints. So
So, I've run across a really nice computer that noone needs for a few
months... Solaris 2.6; 4 Processors, 4GB Ram, 500GB of drive space... that
sort of thing. Is there any useful project out there that can really make
use of this sort of power? I mean, sure, I can run some factoring
programs on
I've not been long involved in GIMPS and noticed the following:-
>So for an exponent like 8027219, you'd save the partial residue at the 10%,
>or 802722th iteration (rounding up or down as normal). Of course, the
>number of iterations varies just slightly from the exponent, but
>whatever...you g
Mersenne Digest Wednesday, August 4 1999 Volume 01 : Number 609
--
Date: Tue, 03 Aug 1999 12:57:28 -0400
From: Jud McCranie <[EMAIL PROTECTED]>
Subject: Mersenne: error 12029
This may have been answered before,
>> 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
> I like the thread of saving multiple residues at various checkpoints along
> the way. George suggested a % completion series. I might suggest a
> specific series of points -- like every L(1000k). This might be
> simpler to
> track in a database although the number of entries grows linearly
>
> Here are some ideas:
>
> 1) You don't need to mail back all the intermediate residues to see if
> they are matching - you only need to send a checksum, which could be
> as small as a few hundred bytes!
or just 4 bytes for a 32 bit residue. Or why not 8 bytes for a nice,
"safe", 64 bit residue.
It seems like there may be three (or more) kinds of problem:
- round-off error gets too large and creates an error (and other unknown
software issues)
- specific hardware failures producing errors
- random occurrences producing errors
mprime95 and the numerous ports and alternatives in GIMPS (I
Here are some ideas:
1) You don't need to mail back all the intermediate residues to see if
they are matching - you only need to send a checksum, which could be
as small as a few hundred bytes!
2) Users could elect how often to save the residue, by % or by
iteration #, depending on their free har
> This had been discussed earlier. Brian and I talked about it for a little
> while, he came up with the original idea.
Doh! Curse my memory! :-)
> > I think the idea has definite merit. If an error does occur,
> it's equally
> > likely to happen at any step along the way, statistically.
> Er
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
> This idea is rather obvious, and no, I don't remember seeing it either.
This had been discussed earlier. Brian and I talked about it for a little
while, he came up with the original idea.
> I think the idea has definite merit. If an error does occur, it's equally
> likely to happen at any st
14 matches
Mail list logo
