> If B's checkpoint info doesn't match A's, the exponent is issued to
> another system C which calculates to the first checkpoint & check in,
> as before. If we now have two matching residuals, the two systems
> supplying them are told to continue and the system with the "wrong"
> result is told to abandon that exponent. If all three differ, issue
> the exponent to system D ...
The main way to speed this up is to have system C continue from the last
residue that it is known that system A and B agree upon. Or, possibly
even better (though more error prone) would be to have A and B recalculate
from last agreed upon residue, and see if they now agree. This would waste
at most 2 P90 months, without having to transfer it over the network, or have
system D doing half the agreed upon work. I think it's safe to say that if
system A and B can agree on the residue at that point, then it is the correct
residue.
> As well as minimising wasted work, this scheme results in very little
> extra server traffic, since the systems all need to check in
> occasionally anyway. If Prime95 is altered so that it always works on
> the _smallest_ exponent it has "in hand", work should be completed
> reasonably quickly and in reasonable order. (Especially bearing in
> mind that this scheme completes double-checking at the same time as
> first tests!)
Won't this mean systems constantly getting interupted in the middle of
an exponent segment?
Or would the systems only continue on one segment when they finish the
current one?
> When a prime is found, the discovery credit (& any prize money)
> should obviously be split between the two users who ran the last
> iteration on the exponent in question.
This makes sense, though it might not be needed. This scheme would work
best on people willing to stay with GIMPS for the decade required to finish
the range. Many of these people have (fast) networks with lots of computers
on them. The check/double check computers might be right next to each other,
owned, and run by the same person.
This will not matter for some time. Does anyone have current data for
% mistakes?
-Lucas
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
