Mersenne Digest       Friday, February 23 2001       Volume 01 : Number 820




----------------------------------------------------------------------

Date: Tue, 20 Feb 2001 11:26:28 +0100
From: "Siegmar Szlavik" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Accuracy of completion dates.

On Mon, 19 Feb 2001 23:02:46 -0500, Jeff Woods wrote:

>>Suggestion: the next version of Prime95 should contact the server after 
>>every 10% of an LL test. Based on how long this took, the server would 
>>calculate the probable finishing time. This estimate would probably be 
>>more accurate than the rough estimate based on how many hours the computer 
>>is estimated to be on which ignores for what the computer is normally 
>>used. The only drawback I see is the strain on the server.
>
>It can already be CONFIGURED to do so, not on percentages, but on number of 
>days between contacts.   I have mine set to report daily, so my individual 
>report is always up to date.
>
Same here... unfortunately ntprime doesn't report to the server if it
is in the 'sleeping mode'. I would find it usefull if it would do so,
or at least on startup - just to say: 'hey, I didn't do any new
calculations, but I'm still here'... for all the office-machines which
are configured to run only over night and on weekends, but are normally
turned off.

Siegmar


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

------------------------------

Date: Tue, 20 Feb 2001 22:17:53 +0100
From: "tom ehlert" <[EMAIL PROTECTED]>
Subject: Mersenne: Mersenne exponent assignement strategie

I personally don't mind a P100 running full LL tests; they are a small, but
usefull contribution to our effort. My own dual P700 makes a  somewhat
larger, but still small contribution to the project, compared to some other
30000+ maschines out there. the point was, is and should remain: every
single cycle is useful.

BUT I think, many people (oncluding me) want to see more Milestones
finisheshed earlier. 
While the server is currently giving out assignment in the 12.3xx.xxx
range, we haven't yet finished 5.558.701.
looking at the status, I would consider 

        LL up to 10.000.000 : 95% done
        DC          4.500.000 : 95% done,
both with a very long tail.

I think, the reason for this is NOT some very slow 486's running dull
screensavers, but exponents, which have been recycled several times.

here's my proposal:
on the server side, set a limit (currently for LL=11.000.000, DC=5.000.000)

define a RPTM= 'reasonable performing, trusted maschine' as a maschine,
which has at least returned 2 results (scince last syncronization?)

then: if a maschine asks for new work:

if its 'reliable and reasonable fast' (has returned two results)
        give it the smallest exponent available
else
        give it some expomnent above limit.


this would:
all overclockers - time out, before they hold the overall progress

favor faster maschines at the tail - they could probably increase the DC
milestone to 10.000.000 whithin a moth, if allowed to

significantly narrow the gap between the frontrunners (12.3xx.xxx) at the
backrunners (~5.300.000)


REPEAT: I don't mind a P100 helping in our project; 

even a P100, runnining 8 hours a day, will finish M12000000 within 2 years,
8 days; I will happily wait for it; the gap between our 12.xx and 5.xx is
larger as the surrent progress (on the front) is roughly 2.500.000/year.



Happy cycling to everybody

tom ehlert





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

------------------------------

Date: Wed, 21 Feb 2001 09:02:12 +0100
From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]>
Subject: Mersenne: Hybernation

>> I personally don't mind a P100 running full LL tests; they are a small,
but
>> usefull contribution to our effort.

I still use an old p100 and p166 to do a full LL test in the 9M range, but i
do check in regularly and make sure that i won't hold up a new milestone.

But i got another question, does anybody have experiance with prime95 and
hybernation?
Does the program pickup where it left correctly?

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

------------------------------

Date: Wed, 21 Feb 2001 11:24:34 +0100
From: "Lukasz Slachciak" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Hybernation

> But i got another question, does anybody have experiance with prime95 and
> hybernation?
> Does the program pickup where it left correctly?
>
> Sander

After your question I've checked it on my Windows 2000 (on Duron 700,
Motherboard AK33). It works correctly, but there is one strange thing. When
I turned power on, after hibernation, the prime 95 showed message:
Iteration.....Per Iteration Time: -52,792 sec. Next iteration times were
showed correctly. I don't know why the time is lower then zero. Maybe
somebody know?


 // Lukasz Slachciak
 // e-mail: [EMAIL PROTECTED]
// Poland


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

------------------------------

Date: Wed, 21 Feb 2001 20:47:53 +0100
From: Philip Heede <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Hybernation

Hi Sander,

Wednesday, February 21, 2001, 11:24:34 AM, you wrote:

>> But i got another question, does anybody have experiance with prime95 and
>> hybernation? Does the program pickup where it left correctly?
>> Sander

While it does work most of the time, I have experienced some problems
when resuming my laptop from suspend and hibernation modes.
The problems seems to occur mostly when Windows (Win2000) attempts to
reinitialize broken network connections. I haven't been able to pinpoint
the exact cause of the trouble though and have transferred my LL-tests
to other (desktop) computers leaving my laptop doing factoring
assignments.

- -- 
Sincerely,
Philip Heede
[EMAIL PROTECTED] / [EMAIL PROTECTED]

... "Bollocks", said Pooh, being more forthright than usual.


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

------------------------------

Date: Wed, 21 Feb 2001 19:55:20 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Mersenne exponent assignement strategie

On 20 Feb 2001, at 22:17, tom ehlert wrote:

> I personally don't mind a P100 running full LL tests; they are a small, but
> usefull contribution to our effort.
> [... snip ...]
> even a P100, runnining 8 hours a day, will finish M12000000 within 2 years,
> 8 days; I will happily wait for it; the gap between our 12.xx and 5.xx is
> larger as the surrent progress (on the front) is roughly 2.500.000/year.

True enough. There are a few issues here:

(a) most users don't seem prepared to wait two years to complete a 
run - even two months is asking a bit much of relatively new users;

(b) a working hypothesis is that random glitches causing runs to go 
wrong happen at a rate which is independent of the system speed - so 
that a given assignment is more likely to give the correct final 
residue if it is run on a fast system rather than a slow one. When 
we're talking about assignments taking years to complete, the chance 
of a random glitch spoiling the result seems to be very real;

(c) so far as PC systems are concerned, the cost of the power used to 
complete an assignment (together with the related environmental 
damage in terms of carbon emissions, if you're worried about global 
warming) is wholly dependent on the run time. Depending on how much 
you pay for utility power, there comes a point where it's actually 
cheaper in the long term to buy new hardware but run it for less 
hours in order to achieve the same processing rate.

Personally I don't _mind_ P100s running LL tests - but I'd rather 
they did double-checks, or factoring, and left the bigger jobs to the 
faster processors.

> here's my proposal:
> on the server side, set a limit (currently for LL=11.000.000,      
> DC=5.000.000)
> 
> define a RPTM= 'reasonable performing, trusted maschine' as a      
> maschine,
> which has at least returned 2 results (scince last syncronization?)
> 
> then: if a maschine asks for new work:
> 
> if its 'reliable and reasonable fast' (has returned two results)
>       give it the smallest exponent available
> else
>       give it some expomnent above limit.
> 

I think this proposal would (a) deter new users and (b) dry up the 
supply of smaller exponents more quickly than the current scheme, 
thereby making the "slow processor problem" worse than it is at 
present.

To implement this scheme, we'd need to change the decision point from 
the user to the server, since the server would have to keep track of 
which systems are "RPTM". At present the user client asks the server 
for a particular type of assignment. I think most people prefer the 
element of free choice implicit in the present method.


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

------------------------------

Date: Wed, 21 Feb 2001 19:55:20 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Hybernation

On 21 Feb 2001, at 11:24, Lukasz Slachciak wrote:

> After your question I've checked it on my Windows 2000 (on Duron 700,
> Motherboard AK33). It works correctly, but there is one strange thing. When
> I turned power on, after hibernation, the prime 95 showed message:
> Iteration.....Per Iteration Time: -52,792 sec. Next iteration times were
> showed correctly. I don't know why the time is lower then zero. Maybe
> somebody know?

Same thing happens on my laptop if I force it to suspend e.g. by 
deliberately running down the battery. Note that it you leave a 
laptop running 24x7 on mains power, the battery will die fairly 
quickly - it needs to be discharged & recharged occasionally if it is 
going to stay healthy.

I guess the CPU cycle counters get set to zero, so when the last 
saved value is subtracted from it, the result is negative. After the 
first line following wake-up, everything is normal.

The residues obtained by continuing the run through the suspend 
operation appear to be as good as any others ...


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

------------------------------

Date: Wed, 21 Feb 2001 23:39:57 EST
From: [EMAIL PROTECTED]
Subject: Mersenne: New version of Mlucas

Dear GIMPSers:

I am pleased to announce Mlucas 2.7b (source code and binaries for
selected platforms) is available. See

ftp://hogranch.com/pub/mayer/README.html
ftp://hogranch.com/pub/mayer/gimps_timings.html

(768kbps capacity) or the mirror at

ftp://209.133.33.182/pub/mayer/README.html
ftp://209.133.33.182/pub/mayer/gimps_timings.html

(160kbps capacity).

The major differences from v2.7a are:

1) New FFT radices, including ones of the form (11,13,15)*2^n. Thus
every interval between adjacent power-of-2 runlengths can be split
into roughly eight equal pieces. Folks testing exponents > 12.59M
and double-checking exponents > 6.39M will (on all but a few of the
older platforms) benefit from the new radix-11 capability. There are
also new larger power-of-2 radices (32 and 64), which allow even very
large runlengths (up to 2^23) to be handled with as few as 6 passes
through the data.

2) Runtime performance optimization for the user's platform. The
program now allows the user to choose from a reasonable set of possible
radices which can be used at each runlength by changing a single entry
in a configuration file. This can be done without interrupting the
program - the file is reread each time a 2000-iteration checkpoint
is reached, and if the prescribed radix set is different from the one
currently being used, the code switches over and prints the actual
new radices being used to the .stat file for the exponent in question.
The elapsed time written to the .stat file at the next checkpoint
can then be used to find the optimal radix set for the current
runlength. Preoptimized configuration files for most major hardware
setups on which the program has been tested accompany the precompiled
binaries, so folks who don't want to fiddle around with this feature
don't have to. Folks who do the runtime tuning will often be rewarded
with a healthy speedup.


If you peruse the timings page, you'll also see that Mlucas now has
competition for the hearts and minds (well, mainly the CPU cycles :)
of the RISC crowd. Guillermo Ballester Valor's excellent C program,
Glucas, is showing excellent performance on most platforms, and even
beats Mlucas on some. Mac/PowerPC users will be especially interested
in Glucas, since it outperforms MacLucasUNIX except for a few narrow
ranges of exponents, and (IMO more importantly) is being actively
maintained and improved. Right now Glucas has only been compiled
using the CodeWarrior C compiler (which I believe has the Gnu C
compiler at its core - correct me if I'm wrong), and we're looking
for folks to compile and do timings on various generations of the
PPC chip, and also who have other compilers, such as the Absoft
suite (whose Fortran-90 compiler could also be used to compile
Mlucas for Mac.)

Anyway, the above links have all the details. Right now I'm really
bushed, so please excuse me while I go sleep for about 12 hours.

Happy hunting,
- -Ernst


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

------------------------------

Date: Thu, 22 Feb 2001 00:37:25 EST
From: [EMAIL PROTECTED]
Subject: Mersenne: New version of Mlucas - acknowledgements

In my haste to make the announcement for the Mlucas 2.7b release
and get to bed, I forgot to thank a very important group of people,
namely my "compile czars" who spent many hours building,
timing and tuning the various binaries:

Brian Beesley - Alpha/Linux
Paul Novarese (Compaq Corp.) - Alpha/TruUnix
Bill Rea - Sparc/Solaris

as well as the following:

Guillermo Ballester Valor - helpful discussions and suggestions for
various code improvements;
David Willmore - for bugging me to get v2.7b released.

My apologies, guys - I couldn't have done it without you!

Cheers,
- -Ernst


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

------------------------------

Date: Thu, 22 Feb 2001 01:14:38 EST
From: [EMAIL PROTECTED]
Subject: Mersenne: New version of Mlucas: p.s.

In my haste to thank the various folks who helped build the Mlucas
2.7b binaries and get *back* to bed, I forgot to thank John Pierce
for kindly hosting the ftp archive on his hogranch.com server.
Thanks, John!

And to all the others I've probably still forgotten to thank, thanks.
(Hopefully that covers everyone :)

Now back back to bed,
- -Ernst


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

------------------------------

Date: Fri, 23 Feb 2001 22:18:52 +0100
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Spontaneous reboots

Hi,

After being away for five days recently, I noticed that my computer
(running Linux kernel 2.4.1, by the way -- 2.4.2 now) had rebooted.
Just a few hours later, it rebooted again -- and that night, it rebooted
_again_.

If I turn off mprime (v20), the problem goes away -- the computer
doesn't reboot, at least not the 36 hours I tested. After I start
mprime, it reboots in just a couple of minutes now.

mprime doesn't run as root, the machine has run mprime stably since I
got it (about a year) and the machine (an Athlon 800, running on an Abit
KA7-100 mainboard) is not overclocked. Does anybody know what's going on
here? Like I said, it's been going fine on the same exponent for quite a
while now, but suddenly, it just feels like rebooting (no error message
or anything, the screen just goes blank and suddenly it's in the BIOS).
The voltage meters in the BIOS screen look OK, and there should be more
than enough power for the PC...

Strange... Any ideas?

/* Steinar */
- -- 
Homepage: http://members.xoom.com/sneeze/
_________________________________________________________________________
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 #820
******************************

Reply via email to