On Sun, 18 Feb 2001 17:49:53 -0000, Brian J. Beesley wrote:
>On 18 Feb 2001, at 2:24, Shane & Amy Sanford wrote:
>> In the
>> OCing community Prime95 has been considered the single best stress test
>> tool available for some time now (especially when used in conjunction with
>> a game that makes heavy use of the 3d side of the computer). No doubt a
>> high percent of these people get a exponent and then abandon it before
>> completion but a few stick around and add significantly to the project.
>
>Sure. I really don't have a problem with that. My point was simply
>that if the options were set up a bit differently, more of those who
>never had any intention of completing a test might not set up in a
>way which causes them to actually take an assignment - which
>effectively ties the assignment up for (by default) 88 days. This in
>itself is not a problem, but the extra transactions on the PrimeNet
>server caused by this "waste" might be, one day.
Indeed; this would also be more convenient for the overclockers, since
they could immediately start a self-test.
>What really does hurt is people starting a test, getting a
>substantial way through & then abandoning.
True. One of the problems GIMPS faces, compared with other
distributed computing projects, is that our 'work units' take weeks or
months; if people joined, e.g., distributed.net for a one-day
self-test, they'd tie up a day's worth of work, and return most of it.
>Another suggestion I might make is that the first assignment given to
>every new user/system should be a doublecheck. (Unless they
>specifically override the assignment type in the Test menu). This
>would complete fast enough to encourage new users by getting their
>name onto the league table, & might encourage more of the "casual"
>users to stay with the project.
On the other hand, some users might become upset at being assigned a
double-check, and not realize that they could change the setting in
question.
>My feeling is that we should be clearing LL & DC assignments at about
>the same rate. If the threshold stays the same then DC assignments
>will start to lag behind as new systems tend to be fast, whilst
>older, slower systems are retired or upgraded. Increasing the
>threshold will switch some of the slower systems from LL assignments
>to DC assignments, thus restoring the balance.
Or course, there's no absolute rule that we must always maintain such
a balance - if LL assignments start building a backlog, people will
become upset at the length of time those assignments are taking, and
will then switch to DC.
>Another way to look at the balance is to examine the PrimeNet status
>report at 0800 UTC. There tends to be a balance of LL assignments
>which were recycled at 0600 still to be reassigned, whereas all the
>recycled DC assignments have usually gone by then.
Of course, many people (particularly members of this list - myself
included) go out of their way to claim the smaller DC assignments when
they are reissued. To be sure, I've done the same with LL before, but
frankly not as often.
>Yet another way is to compare the time taken for a DC assignment on a
>"threshold" system to the time taken for a LL test on a "state of the
>art" system. At present a typical DC assignment on a 300 MHz PII
>takes about half as long to run as a typical LL assignment on a 1.2
>GHz Athlon. Personally I don't feel this is unreasonable.
Of course, the 1.2 Ghx Athlon is right at the top of the "state of the
art", while systems well slower than a PII are still usable.
>Regards
>Brian Beesley
Nathan Russell
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
