Mersenne Digest Sunday, March 11 2001 Volume 01 : Number 826
----------------------------------------------------------------------
Date: Sat, 10 Mar 2001 12:08:09 +0100
From: "Robert van der Peijl" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: numbering the messages
Steve ( [EMAIL PROTECTED] ) wrote on
Saturday, March 10, 2001 at 02:24:00 +0000
> X-Mersenne-Count 229
X-headers, good idea. I agree, no need to reset the message count.
> But having said all of that I don't really think there's much point in
> doing this.
We can't all share the same opinion :-) But I'll ask you this:
how many Mersenne list messages have you missed since you joined the list?
Respectfully, you probably don't know.
Would you want to miss, say, a posting by George Woltman, and not
know about it?
It's common practice in the printed world to consecutively number the
publications.
Besides, I don't think it's that difficult to add a message counter.
(Could you give me a good reason why the server shouldn't number the
messages?)
As Joshua Zelinsky put it: automatic numbering would be pretty helpful.
Maybe Luke Welsh would give his opinion on this subject?
Happy hunting,
Robert van der Peijl
- ------------------------------------------------------------------
Your mouse has moved. Windows NT must be restarted for the
change to take effect. Reboot now? [ OK ] [ YES ] [ APPLY ]
- ------------------------------------------------------------------
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 10 Mar 2001 15:26:08 +0000
From: Steve <[EMAIL PROTECTED]>
Subject: Re: Mersenne: numbering the messages
On Sat, Mar 10, 2001 at 12:08:09PM +0100, Robert van der Peijl wrote:
> We can't all share the same opinion :-) But I'll ask you this:
> how many Mersenne list messages have you missed since you joined the list?
Don't know.
> Respectfully, you probably don't know.
> Would you want to miss, say, a posting by George Woltman, and not
> know about it?
Missed many before I joined the list and the world kept on turning.
> It's common practice in the printed world to consecutively number the
> publications.
> Besides, I don't think it's that difficult to add a message counter.
> (Could you give me a good reason why the server shouldn't number the
> messages?)
Well there isn't a good reason why not, and there is already a counter
of sorts in the Message ID in the header, but it's not very human
readable.
Surely the list management software keeps a count of how many posts have
been sent out to the group, it's just a case of reading/writing that
digit into a header line.
- --
Cheers
Steve email mailto:[EMAIL PROTECTED]
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
3:10pm up 36 days, 16:51, 2 users, load average: 1.16, 1.14, 1.06
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 10 Mar 2001 10:15:15 -0800
From: "John R Pierce" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: numbering the messages
> Well there isn't a good reason why not, and there is already a counter
> of sorts in the Message ID in the header, but it's not very human
> readable.
>
> Surely the list management software keeps a count of how many posts have
> been sent out to the group, it's just a case of reading/writing that
> digit into a header line.
digests are generally numbered, while regular postings are passed thru the
email list server systems relatively unscathed (other than appending the tag
at the bottom). Majordomo at least doesn't keep any sort of counters. I
guess it could be modified to do so, but this could get messy on a large
busy server (afaik, multiple messages can be in the queue at once getting
handled by parallel processes, so updating this counter would have to be
done on an 'atomic' basis... preventing deadlock issues etc complicates
matters)
- -jrp
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 10 Mar 2001 19:56:59 +0100
From: Martijn <[EMAIL PROTECTED]>
Subject: Re: Mersenne: prime95 - v21 progress
This message apperently got lost, so I sent it again
(so sorry if you receive it twice / how appropiate the number though
discussion)
Hello,
when looking at the data it can clearly be seen that computer speed is
not the problem for progress
currently, expiring exponents are.
(Why are checks started on those exponents anyway nowadays, the 3xxxxxx
range was first handed out for
doublecheck in 98 or 99,
there is no computer that had it assigned in 98 or 99 left in the row.)
The funny part, the same holds true
for the 6xxxxxxx range and first checks (at least at a first glance)!
I have made some annotations in the lowest 30 double checks according to
primenet
I have not looked at the days run/togo/exp but at curr it, date updated
date assigned account and
computer ID together with the cleared exp list when doing the
predictions.
A - is an account with no previous data I suspect these will expire.
A = is an account with only 1 previous data nothing can be said here
A ? means something funny is with this account so that no prediction is
possible.
A + means the account exists but not this computer from historical data
Note that as the doublechecks in this range were handed out originally
somewhere in 98 these all must
have expired multiple times.
prime fact current days
exponent bits iteration run / to go / exp date updated date
assigned account
ID computer ID
- -------- -- ---- --------- ----------------- ---------------
- ---------------
- -------------- ------------
3475261 D* 61 1638399 33.5 -6.6 53.4 01-Mar-01 20:44
05-Feb-01 00:53
keithcostello CC7BF71E5 expect March 6 (PII 200 effectively)
3518041 D* 61 1441792 33.4 7.8 61.8 07-Mar-01 05:03
05-Feb-01 01:10
jerky1 C4031A6A1 expect March 17 (PII 50 effectively)
- -3526283 D* 61 33.4 -12.9 47.1 05-Feb-01 13:31
05-Feb-01 01:18
shaft shaft
- -3560023 D* 61 846783 33.4 -5.0 55.0 12-Feb-01 10:58
05-Feb-01 02:29
S36717 C4FDFE920
3682961 D* 61 360128 33.4 1.4 61.4 08-Mar-01 20:34
05-Feb-01 02:47
dismit BX6R2_BT expect March 11 (PII 700 effectively)
3689597 D* 61 33.4 3.4 63.4 08-Mar-01 20:34
05-Feb-01 02:47
dismit BX6R2_BT expect March 14 (Work starts march 11, PII 700
effectively)
?3900433 D* 61 32.8 -26.8 33.2
05-Feb-01 15:27
TempleU-CAS AL22
3985067 D 62 2162688 77.3 -4.5 55.5 18-Feb-01 22:53
23-Dec-00 05:51
vlon-gaucho Mom expect April 8 (PII 30 effectively)
3995161 D* 61 77.3 0.9 60.9 06-Mar-01 08:43
23-Dec-00 05:59
. CD41AEFAF expect March 10 (PII 700 effectively)
=3998413 D* 61 77.2 -48.6 11.4 28-Dec-00 20:30
23-Dec-00 06:16
whenman James_1
4007881 D* 61 77.2 3.9 63.9 06-Mar-01 08:43
23-Dec-00 07:40
. CD41AEFAF expect March 13 (PII 700 effectively)
?4015381 D* 61 77.2 -44.5 15.5 05-Jan-01 00:28
23-Dec-00 07:43
humpback student_dec
- -4037263 D* 61 6.2 56.9 81.9 04-Mar-01 09:14
04-Mar-01 06:14
S39083 C1C0571C0
=4038581 D* 62 312 77.1 -1.5 58.5 25-Feb-01 22:14
23-Dec-00 09:06
SLL_ XPS933
- -4047721 D* 61 77.1 -48.1 10.9
23-Dec-00 09:49
S32998 C16902784
4058777 D* 61 1363008 77.0 6.5 60.5 09-Mar-01 23:51
23-Dec-00 10:05
ArjenRodenhuis P2-300 expect March 15 (Work started march 6th! PII
250 effectively)
4066273 D* 62 77.0 17.5 60.5 09-Mar-01 23:51
23-Dec-00 10:05
ArjenRodenhuis P2-300 expect March 23 (Work starts march 15th! PII
250 effectively)
- -4071647 D* 62 77.0 -51.0 9.0
23-Dec-00 10:23
S33000 C01A113E2
- -4073701 D 61 2801596 268.2 25.1 60.1 09-Mar-01 13:47
15-Jun-00 06:09
S07619 hagw10
- -4105363 D 61 0.2 14.8 74.8
10-Mar-01 06:02 kiste0
- -4106551 D* 61 969216 77.0 -32.6 27.4 24-Jan-01 20:00
23-Dec-00 12:36
S33011 C17ED6CC8
?4119307 D* 61 3371850 133.2 -50.8 7.3 15-Jan-01 17:12
28-Oct-00 06:15
TempleU-CAS AL19
- -4119331 D* 61 76.9 -50.9 9.1
23-Dec-00 13:12
S33013 C5B9E9A51
- -4195183 D* 61 76.8 -57.8 2.2
23-Dec-00 16:27
kris2904 kris2904
- -4195559 D* 62 76.8 -55.8 4.2
23-Dec-00 16:28
. CAD15998F
- -4195621 D 62 76.8 -51.8 8.2
23-Dec-00 16:39
WW WW
?4197839 D* 62 76.8 -49.0 11.0 31-Dec-00 10:02
23-Dec-00 16:47
thomasd NRC
=4198037 D* 61 61119 76.8 -21.7 38.3 21-Jan-01 18:45
23-Dec-00 17:02
ninfanatic 2
- -4198637 D* 61 76.8 -55.8 4.3
23-Dec-00 17:06
daghdha polipop
?4198759 D* 62 76.8 17.2 59.2 17-Feb-01 16:38
23-Dec-00 17:13
OIFFER 1
According to historical data this machine should have started! a new
exponent in Feb 2000 not dec.)
13 computer with no historical data
3 with only 1 measurement point
5 times funny stuff goes on (many computers using 1 computer id, long
gap since last result handed in)
9 computers with 2 LL measurement points that have normal distances
between check ins.
Of the 14 we have historical data on
9 times a prediction could be made (lets see how good that prediction
is)
As we can see the slowest will probably be ready in 30 days and worked
for 100 days then,
This is not the slow down factor!
The 5 with funny stuff 5 times it was known when the exponent was handed
out that something funny
was going on or nothing was handed out yet.
4 of them are more then 10 days over the togo days
Of the 16 computers with insufficient data 11 are more then 10 days over
the days to go and will
probably never check in their results
(80 days delay for that exponent)
Of the 9 computers that have historical date no computer is more than 10
days over the calculated run
and also no togo value less than -10.
This proves that the delay is not caused by slow computers but by
computers that have no track record.
The best way to stop this is not some speed limit (A pentium 60 will do
it in 43 days) but to check that at
least 2 LL results are present in the cleared exponents list before
handing out a re-assigned exponent.
A short look at the lowest part of the first time tests gives the same
results at the first glance. I will have a
look at it if someone is interested.
(Of the first 30 12 alre overdue by more than 10 days and all of these
accounts have no cleared exponents
in the reports list)
Easy to implement and effective assignment proposal for re-assigned
exponents: Check if at least 2 results
have been checked in by that computer in the last 3 months and that
computer has not more then 1
outstanding exponent. (Then the re-assigned exponent will with very high
probability be returned within
60 days)
The really slow reliable one gets filtered out by this rule and all
unreliable ones.
Easier to implement (fairly effective, but not as effective as the 2
results in a timeframe and only one
outstanding) Only re-assign exponents to computers that have already
checked in at least one result.
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
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 10 Mar 2001 21:50:40 +0100
From: "tom ehlert" <[EMAIL PROTECTED]>
Subject: Mersenne: Re: rat race (was prime95 - v21 progress)Re: Mersenne Digest V1
#825
Hi all,
> Is that what we want - an elitist organization which SEGREGATES
> those participants to whom we do not attribute "sufficient calibre"
certainly, NO.
> Is that what we want - an elitist organization which SEGREGATES
> those participants to whom we do not attribute "sufficient calibre" ?
certainly, NO.
>Changing prime95/primenet to only recycle smallest-500
> double-checks and smallest-500 first-time tests to PII-300 or better
> machines might address the concerns of both camps.
> I don't think distinguishing between long-time and new users makes
> sense...
You are right, and not.
I think, the assignement should be based upon something I called few weeks
ago a RPTM = "Reasonable performing, trusted maschine".
I have a P200MMX here, which does one 10million+ assignement every three
months. this may be much better, than a new user 1GHZ athlon, doing a fancy
3D screensaver all the time.
we all probably want only differenciate between maschines, that do deliver
the result sooner or later and those, that simply timeout because of no
activity at all.
I think, that reserving the lowest ~500 LL or DC numbers to maschines, that
seem to run reliable and reasonable fast, is a good idea; a new user will
most probably get a 12million+ number anyway.
and I think, it would be a very easy thing for the server, to give out
numbers below a certain threshold (because they have been recycled), if the
asking maschine has already reported at least one result.
no, this is not elitary thinking; I just want to see everything below
6972593 ( and also below 9.000.000 and other milestones ) done in a
reasonable time; has no to be next month.
best regards
tom ehlert
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 10 Mar 2001 18:54:43 -0500
From: "Joshua Zelinsky" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Security of prime95 + electricity costs.
Brian J. Beesley wrote:
> > 2.What the are actual monetary costs would be of running Prime95. In
> > particular, what are the percentage increases from normal costs.
>
>Depends how much extra you're running the system ... if it's on 24
>hours a day anyway, the answer is _nothing_. Normally I switch off
>monitors on systems left running unattended (this is in any case good
>practise from the fire prevention point of view); power consumption
>of system units does vary but somewhere around 150W would be typical.
>So allow 1 KWh per 6 hours extra running. How much that costs
>obviously depends on how greedy your utility provider is.
What about running all the extra floating point operations? Is there no
significant affect?
Joshua Zelinsky
_________________________________________________________________
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
------------------------------
Date: Sun, 11 Mar 2001 08:59:59 +0100
From: Martijn <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Security of prime95 + electricity costs.
Joshua Zelinsky wrote:
> Brian J. Beesley wrote:
>
> > > 2.What the are actual monetary costs would be of running Prime95. In
> > > particular, what are the percentage increases from normal costs.
> >
> >Depends how much extra you're running the system ... if it's on 24
> >hours a day anyway, the answer is _nothing_. Normally I switch off
> >monitors on systems left running unattended (this is in any case good
> >practise from the fire prevention point of view); power consumption
> >of system units does vary but somewhere around 150W would be typical.
> >So allow 1 KWh per 6 hours extra running. How much that costs
> >obviously depends on how greedy your utility provider is.
> What about running all the extra floating point operations? Is there no
> significant affect?
>
There is a significant diference else there would be no options like do
not run when on battery power and would the temperature of an idle
system not be lower than that of a system running mprime/prime95
With some processors power consuption of an idle processor is less than
1/10th of a busy processor.
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 09:58:00 +-100
From: Denis Cazor <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Security of prime95 + electricity costs.
> 2.What the are actual monetary costs would be of running Prime95. In
> particular, what are the percentage increases from normal costs.
Depends how much extra you're running the system ... if it's on 24
hours a day anyway, the answer is _nothing_. Normally I switch off
monitors on systems left running unattended (this is in any case good
practise from the fire prevention point of view); power consumption
of system units does vary but somewhere around 150W would be typical.
So allow 1 KWh per 6 hours extra running. How much that costs
obviously depends on how greedy your utility provider is.
In winter, when you are heating the house, computer
is just replacing the heating system, at no extra cost.
Regards,
Denis Cazor
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 04:33:36 -0600
From: "Jeramy Ross" <[EMAIL PROTECTED]>
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
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 07:55:04 -0600
From: "Steve" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: prime95 - v21 progress
- -----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
------------------------------
Date: Sun, 11 Mar 2001 12:03:47 -0500
From: "Joshua Zelinsky" <[EMAIL PROTECTED]>
Subject: Mersenne: Ways to increase recruitment.
The vast majority of computers still aren't doing any form of distributed
computing. Here are a few suggestions to help increase GIMPS participation:
1. Get people at major universities + colleges to become "active
recruiters," posting messages on announcement boards, talking to friends and
faculty. We should all be doing this sort of stuff anyways, but if we could
get people to volunteer/coordinate efforts, we might get a lot out of it.
2. Give people/teams some form of credit for recruiting people. This could
be done as competition separate from the main one, or somehow connected. We
could probably have people list an option of listing a "sponsor" or
"sponsors" already on GIMPS when they join. Competition almost always makes
things work better.
3. Post periodic announcements to sci.math and other discussion groups. In
particular, if someone asks a question about Mersenne primes someone should
answer it and throw GIMPS in as well. I'm alrwady doing this, but I can't
get every group. If we organize to split them up, assigning different groups
to different people, it might help out a lot.
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
------------------------------
Date: Sun, 11 Mar 2001 12:34:53 -0500
From: Jeff Woods <[EMAIL PROTECTED]>
Subject: Re: R: Mersenne: prime95 - v21 progress
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(33250000) and is not tolerable to wait eight years for testing M(3250000):
>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
------------------------------
Date: Sun, 11 Mar 2001 19:59:56 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Security of prime95 + electricity costs.
On 11 Mar 2001, at 8:59, Martijn wrote:
> > What about running all the extra floating point operations? Is
> > there no significant affect?
>
> There is a significant diference else there would be no options like do
> not run when on battery power
In theory there should be a difference. In practise the difference in
power consumption is small. Somewhere around 10W seems typical.
I put a current meter on the mains lead of my 1.2 GHz Athlon system,
it registered 0.74A. (We have 240V AC mains power here). I stopped
mprime and the change in current draw was barely perceptible.
CPUs designed for mobile use do tend to use more sophisticated
methods of power consumption control, including turning off parts of
the processor like the FPU whilst they're not in use. Also, 10W is a
much greater fraction of the total power consumption of a laptop PC
than it is of a desktop system unit. However, the option to suspend
Prime95/mprime when operating on battery is really there to reduce
the current drawn from the battery, thereby increasing the run time
before battery recharging is neccessary, rather than to reduce mains
power consumption.
> and would the temperature of an idle
> system not be lower than that of a system running mprime/prime95
Yes, but you have to engineer the cooling to cope with the worst
possible case. However many laptops appear to turn on an extra
cooling fan almost immediately a program which makes use of the FPU
starts.
> With some processors power consuption of an idle processor is less than
> 1/10th of a busy processor.
Yes, using tricks like dropping into a "standby" state where the CPU
clock rate is zero. Signalling an interrupt is required to return the
CPU to normal operation. These techniques reduce the CPU's reaction
speed and are rarely found except in low-drain devices designed for
mobile applications.
Regards
Brian Beesley
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 19:59:56 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
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
------------------------------
Date: Mon, 11 Mar 2002 15:08:13 -0500
From: vincent mooney <[EMAIL PROTECTED]>
Subject: Mersenne: Getting new GIMPSers
see http://www.freechess.org/ for a way to attract GIMPS members.
Freechess.org RC5 cracking team
Is your computer doing all it can? Do you have idle CPU cycles laying
around that aren't doing anything for you? Put those extra cycles to work!
Join the Freechess.Org RC5 cracking team! Team Freechess.Org is currently
participating in the RC5 cracking effort hosted by distributed.net. For
more information on the key cracking effort you are invited to vist
http://www.distributed.net. This site has all the information on the
cracking effort as well as the client you will need to join the team.
If team Freechess.Org wins,
- - $6,000 US will go to a charity selected by the vote of all participants
("The Gutenberg Project" is currently leading here),
- - $2,000 US will go to distributed.net for hosting the effort,
- - $1,000 US will go to the single person who finds the correct key (This
could be you!), and finally
- - $1,000 US will go to FICS to use as they see fit.
If you would like to see how our team is currently doing, please visit
http://rc5stats.distributed.net/rc5-64/tmsummary.php3?team=4264.
Team Freechess.Org looks forward to your participation! If you have any
further questions, please send email to [EMAIL PROTECTED]
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 20:11:33 -0000
From: "Daran" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Security of prime95 + electricity costs.
Hi all. I'm new to the list, but I've been GIMPING for just over two years.
I'd been thinking about possible security risks myself just before I joined
the list, so it's a bit of a coincidence that this was the first thread I
read.
>From: Brian J. Beesley
>Subject: Re: Mersenne: Security of prime95 + electricity costs.
>Date: Fri, 09 Mar 2001 14:25:07 -0800
>
>-----------------------------------------------------------------------------
- ---
>
>On 9 Mar 2001, at 15:35, Joshua Zelinsky wrote:
>
>> 1. How will Prime95 affect security? I don't think there would be any major
>> problems created, but the readme doesn't discuss this much and this isn't
my
>> area of expertise. Any thoughts?
>
>The _only_ security risk to the user associated with Prime95 is the
>same risk associated with downloading and executing _any_ program.
>Possibly we should be providing MD5 checksums to go with the binaries
>so that they can be checked for non-interference.
>
>The network communications between the server and client pose no risk
>as there is no instruction payload. All the code you need is in the
>binary executable and the DLLs supplied.
That doesn't necessarily follow. The 'classic' buffer overrun exploit is
where an attacker deliberately overruns a fixed length buffer, clobbering any
adjacent data and - if the buffer is declared as a local (stack) variable -
the return address of the last subroutine call. In that case, the attacker
can cause the program to 'return' to an arbitrary place within the program's
virtual memory including the clobbered stack, allowing him to execute his own
payload. Result: Potentially the attacker can gain all the privileges of the
attacked program. The fact that the /intended/ messages contain no
instruction payload is irrelevant.
Whether prime95 or any of the other clients (or even the server) has such a
vulnerability I don't know. Has anyone actually checked? If it does, then to
exploit it the attacker would either have to masquerade as the server - rather
difficult to do if communication is always initiated by the client. He would
have to monitor the network (LANs being more vulnerable than the Internet at
large) for server bound packets - or he could crack and compromise the server
itself. This would give him the capability to attack any (or every) client.
A firewall can not protect against this, since client-server communications
are permitted. I would suggest anyone running an Internet client (of any
kind, including browsers) on a *nix system give it it's own UID/GID, and
ensure that no file or directory on the system is world-readable unless it
needs to be. Even this may not be foolproof, since there may be other
vulnerabilities in any given system that could be exploited by the attacker
once he has got a toehold.
I don't know the security models for WIN98/NT/ME But I expect something
similar would be possible. WIN95 and earlier can't be secured in this way.
I would also suggest - if it hasn't already been done - that the message
handling routines in the client do as much sanity checking as possible, and
abort the program /before/ returning if anything untoward is found.
Regards
Daran Gill
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 19:49:59 -0000
From: "Daran" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Security of prime95 + electricity costs.
- -----Original Message-----
From: Denis Cazor <[EMAIL PROTECTED]>
To: 'Brian J. Beesley' <[EMAIL PROTECTED]>; 'Joshua Zelinsky'
<[EMAIL PROTECTED]>
Cc: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]>
Date: 11 March 2001 09:22
Subject: RE: Mersenne: Security of prime95 + electricity costs.
>> 2.What the are actual monetary costs would be of running Prime95. In
>> particular, what are the percentage increases from normal costs.
>
>Depends how much extra you're running the system ... if it's on 24
>hours a day anyway, the answer is _nothing_.
According to the README file, the FPU is shutdown when it's not being used.
Presumably that means it's no longer using power.
[...]
>In winter, when you are heating the house, computer
>is just replacing the heating system, at no extra cost.
With the latest Athlons pushing 50W+ probably the best time for an upgrade is
the autumn. :-)
>Regards,
>Denis Cazor
Daran G.
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 11 Mar 2001 22:57:34 +0100
From: "Martijn Kruithof" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: prime95 - v21 progress
> >
> > 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
------------------------------
End of Mersenne Digest V1 #826
******************************
