Re: Mersenne: prime95 - v21 progress

[Siegmar Szlavik]

On Sun, 11 Mar 2001 07:55:04 -0600, Steve wrote:

[...] As others have mentioned, the problem is NOT slow machines but
rather abandoned exponents, which has nothing to do with machine speeds.

exactly... and that is the point... maybe someone with access to the
server logs can give us a rough estimation of the expired/checked in
exponents ratio, so we better know of what we are talking about...
If it is too high, then I think it would be definitevly worth to find
a way to reduce it, because indirectly it affects the average test
time and recently there have been some 'complaints' about the time to
complete a exponent and this beeing a reason not to join/continue the
project...

recently there were also several remarks regarding the fact, that one
has to wait relatively long compared to other distibuted projects just
to get mentioned for the first time in the top producers list. maybe
we could do something for those who are in for 'competition' on a more
individual/machine basis. It takes a long time to climb the 'highscore
table' with just one computer. What I was thinking of was a sort of
'fastest machine of the day/week/month highscore table' which mainly 
shows a ranking of the best machines which checked in/updated the last
day/week/month, what I think is easy to compute and can be done after
every update/check in. These informations and maybe also some other 
statistical data can be used in combination with the screen saver idea
and displayed on the user screen saying something like: 

"This computer is working on the GIMPS... right now it's the xxx 
fastest machine in the project running at , overall ranking is
; peak performance was  achived on 00-00-. Estimated
time to complete active work: " 

and so on...
...just my 0.02 euro ;-)

greetings,

Siegmar

PS: talking about mailing list server improvements in another thread...
I just noticed, that there is no "Reply-To: [EMAIL PROTECTED]" line in
the header. I would find it usefull if it would be like in other mailing
lists where a reply goes by default to the list and not to the sender.




_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Brian J. Beesley]

On 12 Mar 2001, at 0:20, Alexander Kruppa wrote:

  (1) Removing these assignments from PrimeNet and managing them
  seperately. Anyone who is prepared to make special arrangements to
  acquire these assignments is unlikely to default by reason of lack of
  commitment.
 
 Someone is (or was?) doing something similar - David Campeau (sp?), aka
 diamonddave, who set up scripts to grab small exponents right after the
 Primenet servers recycle run and completed them in ascending order of
 size.

That was unofficial. I meant official, and I meant removing the 
lagging exponents from PrimeNet so that they simply can't be grabbed 
using this sort of technique.

In any case, the "lagging" LL assignments are now in the DC range. 
The "diamonddave" technique simply wouldn't be effective.

 This doesnt help with the exponents that are currently reserved with a
 expected run time of several years - but if the user abandons them, the
 server will recycle them 60 days after the last update from the user
 which doesnt seem like an overly long delay for the project. If the
 users chooses to complete the exponent on a slow machine or on a machine
 that is not in use very often, then I dont see why he shouldnt be
 allowed to do so, delaying a milestone or not.

My suggestion wouldn't cope with that, either. Except by "officially" 
pirating the assignment. I would argue that a competent individual 
administering a relatively small amount of assignments manually 
should be able to make the required judgements.

BTW I agree with Alex that milestones are not the be-all and end-all 
of the project. I'm simply trying to find something that will satisfy 
the "pushers" without upsetting those who are perfectly happy for a 
run to take a long time. Providing, of course, completion does 
eventually occur.


Regards
Brian Beesley
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Steve]

-Original Message-
From: Jeramy Ross [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Sunday, March 11, 2001 5:10 AM
Subject: Re: Mersenne: prime95 - v21 progress


Martijn wrote:
*SNIP*
 Another solution that will work: Have as default a 7 day check in period
 at most and only a grace period
 of 7 days (not 60). Let the user set the check in period to a higher
 value only via the expert menu and
 after results have been checked in. That way abandoned exponents get
 released in 14 instead of 80 days.

 Kind regards, Martijn

That idea sounds the least painful of all that have been discussed so far
(to me at least), and since the discussion of what people want in a new
version of Prime95 has also been floating arround... this sounds like a
good
suggestion to be submitted.  It would not only take care of a problem, but
would also not be so harsh to those who own slower machines.  A win-win
situation from those points of view.  Great idea, Martijn!!

Best wishes,
Jeramy


I agree this is a good idea, although the 7-day grace period may be a little
drastic. But even reducing that just from 60 to 30 days (along with a 7-day
default check in) would release abandoned exponents in 37 days instead of
88. This would recycle them more than twice as fast, greatly enhancing the
odds of someone eventually getting the assignment who will actually finish
it. And I don't believe it would be necessary to put the default changes in
the expert menu; most people seem to not bother changing the defaults
anyway, and it is already impossible to change the defaults until after the
first exponent is assigned (unless you start/set up the program while
offline). As others have mentioned, the problem is NOT slow machines but
rather abandoned exponents, which has nothing to do with machine speeds.
This change would have no effect on those of us who have been regularly
completing our work and reporting it in, regardless of whether or not  we
have slow machines.

Regards,
Steve Harris


_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: R: Mersenne: prime95 - v21 progress

[Jeff Woods]

At 08:13 AM 3/10/01 +0100, you wrote:

this without any polemic spirit, please belive me, enjoy yourself and try to
explain yourself why it is tolerable to wait one year or more for testing
M(3325) and is not tolerable to wait eight years for testing M(325):
is it the first figure really more important than the first just because of
its size?

Actually, the latter is more important (to me) because of its proximity to 
the lower boundary of untested numbers.   Not knowing the former is of 
little importance today in comparison, because there are substantially more 
untested exponents below it.

I'm only saying that I'd rather see the profject working a bit more 
linearly, as opposed to "first come first served" now, so that all machines 
can contribute while at the same time, we make linear progress from zero 
forward, instead of expending the bulk of our efforts on exponents double 
or higher above those untested ones.


_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

RE: Mersenne: prime95 - v21 progress

[Martijn Kruithof]

 
  I agree this is a good idea, although the 7-day grace period
 may be a little
  drastic. But even reducing that just from 60 to 30 days (along
 with a 7-day
  default check in) would release abandoned exponents in 37 days
 instead of
  88. This would recycle them more than twice as fast, greatly
 enhancing the
  odds of someone eventually getting the assignment who will
 actually finish
  it.

 The downside is that there would probably be a great increase in the
 number of assignments which are still running but don't complete
 before the expiry date. Clearly there is a balance to be struck
 somewhere, but 7 days seems to me to be _ludicrously_ short.

 In fact, as assignments take progressively longer to run, the "grace
 period" should be extending, rather than contracting.

 We should also bear in mind the very valuable contributions made by
 those people who do not have permanent (or near-permanent) network
 connections, and those people who are using clients without the
 PrimeNet communication protocol. Requirement to check in frequently
 is off-putting to these people. (Some would put it a lot stronger
 than that!) I don't think we want to risk driving these people out of
 the project.

I have said nothing about not being able to set a longer period,
just set the default one low!

  As others have mentioned, the problem is NOT slow machines but
  rather abandoned exponents, which has nothing to do with machine speeds.

 I fail to see how reducing the check-in interval would have any
 impact on the "problem". Those people who are checking in every 28
 days aren't running into the 60-day expiry deadline.

The reduction of the default check-in interval would recycle the exponents
quicker of people grabbing but not testing exponents.

 The 60 day expiry value is a server parameter, not a client
 parameter. In any case, as I explained above, I think that a drastic
 reduction in the value would be dangerous.

Certainly not for first time assignments, the results are re-used as double
checks right away. People with non frequent contact could put their time
between
check ins up. (could we let the grace period be the same as the time set
between
check ins on the client with a minimum of 7 days?)

 Might I suggest a couple of alternative approaches. Both of these
 would require the identification of exponents which are "seriously
 lagging" - perhaps the 100 smallest outstanding LL and the 100
 smallest outstanding DC assignments.

 (1) Removing these assignments from PrimeNet and managing them
 seperately. Anyone who is prepared to make special arrangements to
 acquire these assignments is unlikely to default by reason of lack of
 commitment.

Seems reasonable, see proposal on bottom (which saves the 100 smalles checks
needed)

 (2) Alternatively, awarding double PrimeNet CPU time credit for the
 completion of these assignments. The downside to this is that, as
 well as requiring changes to the server software, recycled "small"
 exponents would have to be released at random times of the day, to
 prevent them being systematically "grabbed" by a few users.

Will not work, someone working on a exponent is always good (also if he/she
takes a year)
Someone who will forget about their exponent and not check in will not care
if he/she would
have gotten double points for these assignments.

Now the next proposal:
Let Primenet reassign automatically only exponents with a exp date  -5.
Make it possible that a user can explicitly request an exponent with an exp
date between -0.1 and -5. (Primenet could have 2 reactions ok (and the list
gets
updated at the next hour) or not ok (exponent not expired
(yet/anymore)/exponent has been
checked in))
Primenet is already able to assign unassigned specific exponenents to
someone.
(Just try to send an update on a unreserved exponent, you will be listed)
When trying to check in a status on an reserved exponent you will get an
error message.
I just do not know how it exactly works with recycling expired exponents.
Most of the time
they come aroun 6:00 status time, but sometimes the come really bulky at
"random" times.

This makes it possible for the people that want to "hunt" the holes to hunt
those holes.

Maybe we could also update the client to not accept exponents it will work
on for longer
than lets say 2 years, and then let the client get another type of
assignment automatically.

Kind regards, Martijn

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Alexander Kruppa]

"Brian J. Beesley" wrote:

 (1) Removing these assignments from PrimeNet and managing them
 seperately. Anyone who is prepared to make special arrangements to
 acquire these assignments is unlikely to default by reason of lack of
 commitment.

Someone is (or was?) doing something similar - David Campeau (sp?), aka
diamonddave, who set up scripts to grab small exponents right after the
Primenet servers recycle run and completed them in ascending order of
size. And boy, did he get flamed for it. Right, flamed - because some
only looked at the 20 or so small exponents he had reserved and tought
he was holding them back. 

Maybe those who complain about slow "linear" progress could take on a
similar approach? (except for the getting flamed part, I hope.) Write a
script that (or get up early/stay up late to) get exponents right after
the servers recycle run and immediately release the biggest ones so you
have enough work for, say, 30 days. Maybe David can help with the
scripts or general tips for maintaining the exponents list, *especially*
safe guards so that reserved exponents dont pile up in an uncontrolled
manner.
If everyone sticks to the rules - dont poach, dont hog exponents - this
should solve most of the problem with the least possible hassle. Those
who want to see milestones soon can help to get there, the rest can just
go on with their regularly assigned work. 
This doesnt help with the exponents that are currently reserved with a
expected run time of several years - but if the user abandons them, the
server will recycle them 60 days after the last update from the user
which doesnt seem like an overly long delay for the project. If the
users chooses to complete the exponent on a slow machine or on a machine
that is not in use very often, then I dont see why he shouldnt be
allowed to do so, delaying a milestone or not.

Ciao,
  Alex.
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Steve]

I said the idea to set the DEFAULTS lower was a good one. Anyone who is
serious about the project could very easily change those defaults. I have
several machines with dialup access which don't connect with the server for
weeks at a time, but a 7-day default would not affect me in the least. I
change the settings on each machine depending on its circumstances; I have
some set for 39 days. (Even a 1-day default wouldn't bother those machines,
but I did say I thought 7 days might be a little drastic.)  The people who
abandon exponents are the ones who would not bother changing the defaults,
hence returning them sooner.

Steve Harris

-Original Message-
From: Brian J. Beesley [EMAIL PROTECTED]
To: Steve [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Sunday, March 11, 2001 2:44 PM
Subject: Re: Mersenne: prime95 - v21 progress


On 11 Mar 2001, at 7:55, Steve wrote:

  Another solution that will work: Have as default a 7 day check in
period
  at most and only a grace period
  of 7 days (not 60). Let the user set the check in period to a higher
  value only via the expert menu and
  after results have been checked in. That way abandoned exponents get
  released in 14 instead of 80 days.
 
 That idea sounds the least painful of all that have been discussed so far
 (to me at least), and since the discussion of what people want in a new
 version of Prime95 has also been floating arround... this sounds like a
 good
 suggestion to be submitted.  It would not only take care of a problem,
but
 would also not be so harsh to those who own slower machines.  A win-win
 situation from those points of view.  Great idea, Martijn!!

 I agree this is a good idea, although the 7-day grace period may be a
little
 drastic. But even reducing that just from 60 to 30 days (along with a
7-day
 default check in) would release abandoned exponents in 37 days instead of
 88. This would recycle them more than twice as fast, greatly enhancing the
 odds of someone eventually getting the assignment who will actually finish
 it.

The downside is that there would probably be a great increase in the
number of assignments which are still running but don't complete
before the expiry date. Clearly there is a balance to be struck
somewhere, but 7 days seems to me to be _ludicrously_ short.

In fact, as assignments take progressively longer to run, the "grace
period" should be extending, rather than contracting.

We should also bear in mind the very valuable contributions made by
those people who do not have permanent (or near-permanent) network
connections, and those people who are using clients without the
PrimeNet communication protocol. Requirement to check in frequently
is off-putting to these people. (Some would put it a lot stronger
than that!) I don't think we want to risk driving these people out of
the project.

 As others have mentioned, the problem is NOT slow machines but
 rather abandoned exponents, which has nothing to do with machine speeds.

I fail to see how reducing the check-in interval would have any
impact on the "problem". Those people who are checking in every 28
days aren't running into the 60-day expiry deadline.

The 60 day expiry value is a server parameter, not a client
parameter. In any case, as I explained above, I think that a drastic
reduction in the value would be dangerous.

Might I suggest a couple of alternative approaches. Both of these
would require the identification of exponents which are "seriously
lagging" - perhaps the 100 smallest outstanding LL and the 100
smallest outstanding DC assignments.

(1) Removing these assignments from PrimeNet and managing them
seperately. Anyone who is prepared to make special arrangements to
acquire these assignments is unlikely to default by reason of lack of
commitment.

(2) Alternatively, awarding double PrimeNet CPU time credit for the
completion of these assignments. The downside to this is that, as
well as requiring changes to the server software, recycled "small"
exponents would have to be released at random times of the day, to
prevent them being systematically "grabbed" by a few users.


Regards
Brian Beesley
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Jeramy Ross]

Brian J. Beesley wrote:

 I fail to see how reducing the check-in interval would have any
 impact on the "problem". Those people who are checking in every 28
 days aren't running into the 60-day expiry deadline.

For one, the reduced check in time would allow the closer watch of "suspect"
users who download a exp., run the program for a few days and then ditch out
on the project.  While it is true that people may run the program for
upwards of a month or so and then ditch.  The idea of having them check in
about every week AS A DEFAULT too keep tabs on them while they have their
FIRST exp. would aid in finding someone who ditches out.  The process in
which we use this aid is up in the air.


 The 60 day expiry value is a server parameter, not a client
 parameter. In any case, as I explained above, I think that a drastic
 reduction in the value would be dangerous.

I think it is realized that the 60 day value is a server parameter, and the
change in value would be only effective for FIRST TIME users.  Besides, I
don't know of many users who have a problem checking in every week to keep
things moving smoothly.

Best wishes,
Jeramy

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Brian J. Beesley]

On 9 Mar 2001, at 17:27, Jeff Woods wrote:

 Actually, the next obvious milestone is checking all below M(6972593) for 
 the first time.   There are 67 exponents unchecked at all below that 
 exponent, and that number has been VERY VERY slow to reduce, mainly due to 
 number campers or 386's trying to test that number.

Or fast systems slowing because an animated screensaver is being run? 
This can easily happen if you ask someone else to run Prime95 on 
their system as a favour.
 
 I also massaged today's assignments report, and found that there are over 
 200 exponents assigned over a year ago (and some as far back as 1998), NOT 
 including those expected to take that long (i.e. 33 million+).   Some 
 exponents have been run for over a year, and have "days to run" estimates 
 of 2900 days or more -- yes, nearly EIGHT YEARS.

I remember getting "wound up" about this shortly after I joined the 
project. George replied that these problems have a way of sorting 
themselves out; experience proves him right.
 
 The point is that we could crank through these laggards if the Primenet 
 server would have simply ensured they were assigned to a "top 1000" 
 producer, or to a machine of sufficient calibre and reliability 
 (historically, per prior test results).

To which [EMAIL PROTECTED] (Mikus Grinbergs) replied:

 Is that what we want - an elitist organization which SEGREGATES
 those participants to whom we do not attribute "sufficient calibre" 

Well _I_ don't!

Back to Jeff Woods:
 
 You said you had a good reason not to do that, but didn't want to post it 
 here (you were going to mail it privately to Henk).   Why not discuss it here?
 
Now I believe Henk is a responsible individual, and I've no reason to 
suspect Jeff is any less so. The system we have at the moment is 
reasonably robust and will stand a certain amount of abuse. However, 
abuse on a large scale will break it. I don't want to be responsible 
for that. What I mailed to Henk privately amounts to a minor form of 
abuse of the system. One paragraph of that private message reads:

(start quote)
Obviously you should be careful when doing this, else you are likely 
to be accused of "pirating" assignments. Also there would be chaos if 
several people were doing this, which is why this reply is being sent 
to you only and not to the list.
(end quote)

Jeff, if you (or anyone else, for that matter) want to take advantage 
of the idea I mailed to Henk, I suggest you mail Henk privately and 
discuss amongst yourselves how you're going to coordinate your 
combined effort. My contribution to your "sturmgruppe" ends here 
because I don't believe that anyone's CPU cycles are inherently more 
valuable than anyone else's.

Oh, and if you happen to find a new Mersenne prime whilst you're 
working in this mode, I would hope that you'd be prepared to share 
the credit with any other person who happens to "own" the PrimeNet 
assignment at the time.


Regards
Brian Beesley
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

RE: Mersenne: prime95 - v21 progress

[Martijn Kruithof]

Hello,

because of the discussion about the speed on the slowest exponents I did
some calculations:
Result:
The limits like 750 MHz or even 350 MHz for the smalles exponents are
completely ridiculous, certainly if we do not take into account the number
of it is on, a 1000 MHz machine on for 8x5 hours a week will take longer
than PII 233 on 24x7.
If we want to get it done as soon as possible we must calculate what would
be fastest:

Observation the relatively slow machines are often used as servers / private
firewalls and on 24x7
On the other hand relatively slow machines may be hardly on.

Some calculations (benchmark page) on the fictive exponent 400 yields
24x7 on a:
486@33: 1Y+182 days (Ok that seems long)
PI@60:  43 days (Seems we can wait on that, as long as the machine is
reliable)
PII@233: 10 days (Seems as of now it really does not matter anymore)
Cel@300: 8 days
PIII@450: 6 days
PIII@1000: 3 days
Athlon@1200: 2 days

Some calculations on the ficive exponent 800 (486 left out)
PI@60 : 177 days (Doubtfull)
PII@233 : 40 days (Seems we can wait on that, as long as the machine is
reliable)
Cel@300 : 31 days
PIII@450 : 23 days
PIII@1000 : 12 days
Athlon@1200 : 9 days

Some calculations on the ficive exponent 1200 (486 left out)
PI@60 : 1Y+29 days (Seems to long)
PII@233 : 87 days
Cel@300 : 68 days
PIII@450 : 50 days
PIII@1000 : 27 days
Athlon@1200 : 17 days

When we take into account that the timeout offset is 60 days (so someone
starting an assignment and not doing anything at all costs 60 days, nobody
works on the exp. so that is a delay of the entire project) We should
probably reassign exponents to machines that have already
finished at least 2 exponents, and based on that info will return this
assignment within 60 days.
That would be like doublechecks reassigns for PI / PII / Celeron, Primality
reassigns for PIII / Athlon.

Exponents in the lower 10% of a range should be reassigned if no progress
has been reported for 60 days.

A good better solution optimizing for progress would be to re-assign expired
exponents to machines that have finished exponents already and will finish
them in for instance approximately 20 days (Assigning the smaller exponents
to slower machines and larger exponents to faster machines) The actual
number of days can be calculated from the "ballpark". So that optimal
progress is made. We must try to keep slow machines in as long as possible
as they really contribute to the progress.

So optimal progress will be made by giving smaller machines small exponents
and larger machines large.

Kind Regards, Martijn

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Brian J. Beesley]

On 9 Mar 2001, at 0:45, Henk Stokhorst wrote:

 Maybe it would be a good idea to have a special version of prime95 that 
 has an option to request exponents that have expired after having been 
 reserved for a long time without any progress being on the work for that 
 exponent.

No need for this. Henk, I'll mail you privately explaining why.

 The server should issue those exponents only to people who 
 have that option.

Two problems here: 

(a) needs a server fix; with due respect I think there are other 
things which need fixing more urgently e.g. keeping proper tabs on 
P-1 so that work is not replicated wastefully.

(b) reeks of elitism. Whilst I understand your motives, I think there 
are a lot of people who would object for that reason.

 That would help prevent exponents expiring multiple times.

Is that _really_ a problem? If anything it only points out a lack of 
commitment to the project amongst some of the contributors.


Regards
Brian Beesley
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: prime95 - v21 progress

[Dennis Pope]

Robert van der Peijl [EMAIL PROTECTED] wrote on Wed, 7 Mar 2001
03:11:22 +0100:
We would have to uglify (is that good English?) the user interface
however, to make the whole thing believable.

In answer to your question, Alice didn't think so:
`I only took the regular course,' said the Mock Turtle with a sigh.

`What was that?' inquired Alice. 

`Reeling and Writhing, of course, to begin with,' the Mock Turtle
replied; `and then the different branches of
Arithmetic-- Ambition, Distraction, Uglification, and Derision.' 

`I never heard of "Uglification," Alice ventured to say. `What is it?' 

The Gryphon lifted up both its paws in surprise. `What! Never heard of
uglifying!' it exclaimed. `You know what to beautify is, I suppose?' 

`Yes,' said Alice doubtfully: `it means--to--make--anything-- prettier.' 

`Well, then,' the Gryphon went on, `if you don't know what to uglify is,
you ARE a simpleton.'

from Alice's Adventures in Wonderland, by Lewis Carroll

Lewis Carroll was a Professor of Mathematics (a rather dull one, if the
stories are true) but this small book, written to entertain a little
girl, is what has eternalized his name (not to put a damper on anyone's
day).

By the way...  "Eternalized"...  Is that good English?

Best regards,
Dennis Pope
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Jeff Woods]

At 11:09 AM 3/9/01 +, you wrote:

  That would help prevent exponents expiring multiple times.

Is that _really_ a problem? If anything it only points out a lack of
commitment to the project amongst some of the contributors.

*THAT* is precisely the reason that such people should not be assigned the 
very exponents that are most necessary to reaching the next 
"milestones".   For those of us that measure progress both in Teraflops and 
in milestones, we've not seen much lately, mainly due to the things that 
Henk was complaining about.
_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Jeff Woods]

At 10:00 PM 3/9/01 +, you wrote:

Isn't the "problem" just that the milestones are rather a long way
apart at the moment? Does it _really_ matter that there's an
outstanding exponent around 3.25 million which needs double-checking
when there are so many more to go before we complete double-checking
up to 6973593 - which is the next obvious milestone, after completing
coverage of first tests up to that value, and always assuming that we
don't find another prime smaller than Hajratwala's Number in the
meantime?

Actually, the next obvious milestone is checking all below M(6972593) for 
the first time.   There are 67 exponents unchecked at all below that 
exponent, and that number has been VERY VERY slow to reduce, mainly due to 
number campers or 386's trying to test that number.

I also massaged today's assignments report, and found that there are over 
200 exponents assigned over a year ago (and some as far back as 1998), NOT 
including those expected to take that long (i.e. 33 million+).   Some 
exponents have been run for over a year, and have "days to run" estimates 
of 2900 days or more -- yes, nearly EIGHT YEARS.

The point is that we could crank through these laggards if the Primenet 
server would have simply ensured they were assigned to a "top 1000" 
producer, or to a machine of sufficient calibre and reliability 
(historically, per prior test results).

You said you had a good reason not to do that, but didn't want to post it 
here (you were going to mail it privately to Henk).   Why not discuss it here?

Somehow the laggards always do get swept up in the end; there seems
to be an adequate supply of self-appointed "gap fillers" (or pirates,
according to your point of view). The result is that many of the
assignments which are the "longest overdue" eventually end up with
three, four or even more completed LL tests.

Said "overchecking" could be eliminated by ensuring that the oldest 
exponents are assigned to the most reliable machines possible.


_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Mikus Grinbergs]

On Fri, 09 Mar 2001 10:12:43 -0500 Jeff Woods [EMAIL PROTECTED] wrote:
 At 11:09 AM 3/9/01 +, you wrote:

   That would help prevent exponents expiring multiple times.
 
 Is that _really_ a problem? If anything it only points out a lack of
 commitment to the project amongst some of the contributors.

 *THAT* is precisely the reason that such people should not be assigned the
 very exponents that are most necessary to reaching the next
 "milestones".   For those of us that measure progress both in Teraflops and
 in milestones, we've not seen much lately, mainly due to the things that
 Henk was complaining about.

I consider the attitude "GOTTA GET IT DONE" to be rat-race oriented
rather than thank-you-for-participating oriented.  It implies to
those with less-than-state-of-the-art equipment:  "__You__ are an
obstacle in the way of GOTTA GET IT DONE -- there are no seats for
you on this bus".

Would the world come to an end tomorrow if the GIMPS participants were
more tolerant of those who do __not__ measure progress in Teraflops ?

mikus

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Mikus Grinbergs]

On Fri, 09 Mar 2001 17:27:42 -0500 Jeff Woods [EMAIL PROTECTED] wrote:

 The point is that we could crank through these laggards if the Primenet
 server would have simply ensured they were assigned to a "top 1000"
 producer, or to a machine of sufficient calibre and reliability
 (historically, per prior test results).

Is that what we want - an elitist organization which SEGREGATES
those participants to whom we do not attribute "sufficient calibre" ?


 Why not discuss it here?

I thought this project was an association of VOLUNTEERS.
I believe we should welcome ALL who offer to participate.

mikus

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Robert van der Peijl]

Joshua Zelinsky wrote on Thursday, March 08, 2001 3:38 AM

   I'm betting this is a rather significant penalty!  You have to use the
   wall clock to time your iterations / minute.  Prime95 will report the
   same time, but it is only measuring the time to do an iteration,
   not the additional time to write to the display.
 
 Still, the CPU time required to write one line to the display is
 considerably less than that required to execute one iteration of an
 LL test on a large exponent.

 I just did a test as George suggested.

Thanx, I never get around to actually testing things. I had been wondering
myself about the performance penalty.

 The average ratio for the with results at every 1 iteration came out
 to be .540 per for .487 every 100 iterations. I'm running a
 PIII 600 megahertz and I didn't realize that I had my webbrowser
 open when I ran the test which seriously invalidates the results.

That much difference -- 10 PERCENT! That's too rich for my blood.
I'll have to shtick with the standard setting.

 I might run a test again later when I get a chance...

Let us know what you come up with; I own a P3-600 myself.

By the way, I think Joshua's suggestion from Feb 12 2001 for Prime95 to have
an option for disk writes to occur based on the number of iterations, rather
than the time passed, is a sound idea.
I hope it will make it into Prime95 v21.

Brian Beesley wrote on Wed, 7 Mar 2001 20:56:12 -
 Don't fix what ain't broke.
Right on.
 If you must change the name [Prime95]...
Yes, if someone successfully challenges our rights to that name.
Has anyone of us bothered to register the name Prime95 as a trademark?
I sure haven't.
..., go for PriMe.
That looks like a very modern name to Me.

By the way, a release of v21 in more than 6 months would suit me just fine.
And, George, hand-holding can be rewarding too, it just takes up so much
time.
I think most people wouldn't mind the slight file size increase with
the optional screensaver part.

George's efforts to understand the strengths and weaknesses of the P4
architecture could present an opportunity for the engineers at Intel to
pitch in. It may be in the chip manufacturer's interest!

Also, on Feb 3 2001 Joshua Zelinski wrote:

Recently people have been discussing that the long times it takes to
finish a batch of work makes GIMPS less appealing than other distributed
computing systems. What if we gave out factoring in small bunches...

Yeah, I like that idea! Giving peoply bite-sized chuncks would make them
come back, craving for more. It would make GIMPS less appalling, that is,
more appealing to the novice. Even a factoring assignment from 2^n to
2^(n+1) could theoretically be cut up into up to 16 little snack-sized
appetizers. (All this talk is starting to wet my appetite)

I'm off to lunch now, cheers.
Robert.

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Henk Stokhorst]

L.S.,

Maybe it would be a good idea to have a special version of prime95 that 
has an option to request exponents that have expired after having been 
reserved for a long time without any progress being on the work for that 
exponent. The server should issue those exponents only to people who 
have that option. That version should only be available to people who 
have fast (700 MHz or more) machines running most of the day. That would 
help prevent exponents expiring multiple times.

YotN,

Henk Stokhorst

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Martijn]

Henk Stokhorst wrote:

 L.S.,

 Maybe it would be a good idea to have a special version of prime95 that
 has an option to request exponents that have expired after having been
 reserved for a long time without any progress being on the work for that
 exponent. The server should issue those exponents only to people who
 have that option. That version should only be available to people who
 have fast (700 MHz or more) machines running most of the day. That would
 help prevent exponents expiring multiple times.

 YotN,

 Henk Stokhorst

Nope bad idea smaller exponent = smaller runtime = lower clock frequency
so it would then be better to have them assigned to machines that are slow
real pentiums for instance (It does really not matter if such an exponent is
finished in 4 or 30 days.

The multple expiering problem is an entirely fake one. It does not hinder
progress, it only makes (relatively small) exponents unavailable for 90
days, in that time we work on other exponents and life goes on.

Martijn Kruithof

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[George Woltman]

Hi,

At 03:11 AM 3/7/2001 +0100, Robert van der Peijl wrote:
Could it be that's because everyone is holding their breath for prime95 v21?
But that might still take quite a while, since AFAIK no public 
announcement has been
made about its scheduled completion date.

I have no idea when a new release will be available.  I've done no work on 
prime95
from v20 release until last December.  Since then all available time has been
devoted to a P4 version of prime95.  Much of this has been writing code samples
to understand the strengths and weaknesses of the architecture.  This is not
particularly easy - a lot like reverse engineering chip design.

After a P4 recoding, I'll look at what new features to add to a v21 release.
I liked the screensaver ideas recently suggested, but would like to have one
executable that runs like it does now, as a screensaver only, or both.
I've received many other minor suggestions which I dutifully write down and
implement the easiest and/or most useful.

In any event, I cannot imagine a release of v21 in less than 6 months.

Hey, how about calling it primeXP?

Several versions ago, I thought about renaming prime95 to prime98.  However,
the upgrade issues are enormous.  I can just imagine hundreds of users
running both prime95 and primeXP on their machine - then a flood of email
questions and hand-holding.

  I was thinking of switching my iterations between screen outputs to 1 
 for Prime95,
just to make it "feel faster."
  However, I wasn't sure how much resources it would take up. I checked 
 and it seems
negligible. Is that true?

I'm betting this is a rather significant penalty!  You have to use the wall 
clock
to time your iterations / minute.  Prime95 will report the same time, but it is
only measuring the time to do an iteration, not the additional time to write to
the display.

Have fun,
George

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: prime95 - v21 progress

[Joshua Zelinsky]

  I'm betting this is a rather significant penalty!  You have to use the 
wall
  clock
  to time your iterations / minute.  Prime95 will report the same time, 
but it is
  only measuring the time to do an iteration, not the additional time to 
write to
  the display.

Still, the CPU time required to write one line to the display is
considerably less than that required to execute one iteration of an
LL test on a large exponent.

I just did a test as George suggested. The average ratio for the with 
results at every 1 iteration came out to be .540 per for .487 every 100 
iterations. I'm running a PIII 600 megahertz and I didn't realize that I had 
my webbrowser open when I ran the test which seriously invalidates the 
results. I might run a test again later when I get a chance but right now it 
looks like George is right.

Sincerely,
Joshua Zelinsky
[EMAIL PROTECTED]
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: prime95 - v21 progress

[Robert van der Peijl]

Joshua Zelinsky wrote on Tuesday, March 06, 2001 at 17:08:37 -0500 :

 The list has been pretty quiet lately...

Could it be that's because everyone is holding their breath for prime95 v21?
But that might still take quite a while, since AFAIK no public announcement has been
made about its scheduled completion date. Of course, that date would depend on the
intended new features. Still, some indication would useful -- say, between 3 and 9
months from now?? Personally, it would help me in deciding whether to continue
translating the v20 readme file into my language (Dutch), or to wait for the new
stuff.
Hey, how about calling it primeXP? It would allow the new user to run only 50
iterations, after which time registration is mandatory. We would have to uglify (is
that good English?) the user interface however, to make the whole thing believable.
And, existing software should no longer be able to execute with our new version.
Those two criteria may be quite hard for us to fulfill. What software company could
we ask to implement those changes for us?
The Good Thing (TM) would be, that no new features would be necessary. But then we'd
have to charge a lot of money for the product. The revenues could go to Bill Gates'
family -- to help them extend their house.

 This is a little embarrassing but ...

That's quite allright, this is a private conversation, right? :-)

 I was thinking of switching my iterations between screen outputs to 1 for Prime95,
just to make it "feel faster."

Actually, I have several alternative suggestions to make it, how did you put it,
'feel faster'? Do something fun. Don't look at prime95's output. Go read a good
book. Go on a long vacation. You name it.

 However, I wasn't sure how much resources it would take up. I checked and it seems
negligible. Is that true?

If you say so. You say you checked, right?
But, seriously: yes, a first time LL test on a new exponent would complete about as
fast with "iterations between screen outputs" = 1.

 Are there any other reasons to set the number that low?

You tell me -- are there?

Hope this answers your question. It doesn't answer mine.
Cheers,
Robert.

P.S. Sorry for this lame response, but I was getting bored looking at prime95's
screen output. ;-)

_
Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers