On 25 Mar 00, at 23:14, Geoffrey Faivre-Malloy wrote:
> The problem was caused by me testing the FactorOverride option and setting
> it to an abusrdly low value (56). The end result was that each exponent
> was test to to this value then the results were reported and it was
> removed from the worktodo.ini. Since it only took a minute for it to
> reach this high on the computer it was running, about 60 exponents per
> hour (sometimes more) were getting reserved. I say sometimes more because
> if the exponent had already been tested to 56 or higher, it would
> immediately go to the next exponent.
Thanks for "coming clean".
>
> Is it a bug? not really as it's a previously undocumented feature in
> Prime95 and the document now says not to use it with primenet. IMHO, it's
> a shame really because it'd be really cool if primenet could take the
> exponent back and release it. It would allow those who want to only test
> to a certain limit to have the ability to do so (those who have slower
> machines maybe).
I'd call it an "unwanted feature". George, I think perhaps the easy
way to handle this would be to check "UsePrimeNet" and refuse to
execute AdvancedFactor assignments if UsePrimeNet=1.
I appreciate the point about slower machines. One way to deal with
this would be a few small changes to Prime95, and a small enhancement
to PrimeNet.
It could go something like this:
Prime95 would have a new parameter for the maximum elapsed time for a
factoring assignment. When it completes to a depth of n bits, before
going on to (n+1) bits it checks if the max elapsed time would be
exceeded. If so, it reports "no factor found to 2^n", signals
PrimeNet that it is abandoning work on this exponent & goes on to the
next assignment. (I think that this is purely client end so far,
since there is already a mechanism to return an unwanted assignment,
both in the manual testing pages and invoked from "Quit Gimps".)
When requesting factoring assignments, Prime95 would tell PrimeNet
the maximum number of bits pre-factored it was prepared to accept
assignments for (this could be calculated approximately from the max
factoring assignment time parameter) . This requires a change to the
server as well as to the client to accommodate, since the server
would have to scan down the list of available factoring assignments
until it found a suitable candidate.
However it is also possible that slower machines with reasonable
amounts of memory could find a role running P-1 assignments, when
they become available. Note that this is dependent on a major change
to the server software, so maybe now is a good time to specify the
relatively minor change needed to accommodate a scheme similar to the
above.
A more general & more secure method of preventing the type of problem
exposed by this incident would be to have the server enforce a quota
for the maximum number of assignments issued to any user/computer id
combo in a particular time interval e.g. 20 per day. Yes, this could
still be got round by anyone determined to cause mischief by changing
the computer id and grabbing another bunch of assignments, but it
would be effective against accidents.
Regards
Brian Beesley
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
