Mersenne Digest Tuesday, March 7 2000 Volume 01 : Number 703
----------------------------------------------------------------------
Date: Sun, 05 Mar 2000 17:45:29 -0800
From: Stefan Struiker <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Mersenne Timings
Ethan O'Connor wrote:
> Having woken up too early this morning, I put the numbers
> available at http://www.mersenne.org/bench.htm into an Excel
> worksheet and very briefly played with them. The worksheet is
> available at http://web.mit.edu/zudark/www/MersenneSpeeds.xls
I find the Athlon 500 speeds truly astounding. Are other Athlon users
in the quad getting this kind of performance?
Best Regards,
Stefanovic
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 6 Mar 2000 07:39:26 +0100
From: =?ISO-8859-1?Q?H=E4nggi_Philipp?= <[EMAIL PROTECTED]>
Subject: Mersenne: RE: Mersenne Digest V1 #701
Hi!
My Laptop (DELL Inspiron 5000) makes a high frequency noise (low volume) as
long as prime is running.
If I stop prime the noise stops. If I choose continue it comes back again.
If I use a chess program, which also grabs 100% CPU, there's no noise.
What should I do.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 6 Mar 2000 10:51:42 +0100
From: =?ISO-8859-1?Q?H=E4nggi_Philipp?= <[EMAIL PROTECTED]>
Subject: Mersenne: Bug Report: Wrong timing for Intel Speedstep
Hi all
I use a Dell Inspiron 5000 Laptop with the new Intel Speedstep feature.
Which meens that the box runs with 500Mhz on battery and 600Mhz on net power
supply.
My exponet 9066011 is timed with 0.233 secs/iter for 500Mhz and with 0.255
secs/iter for 600Mhz !!!
No, I didn't mix the modes up. But I validated the timing with a stop watch.
The true timings are 0.233 secs/iter for 500Mhz and ~0.200 secs/iter for
600Mhz.
So somethings goes wrong in the calculation of prime95.
By the way, I use windows 98 second release.
Any Ideas ?
Philipp
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sun, 5 Mar 2000 22:58:31 -0000
From: "Tom Womack" <[EMAIL PROTECTED]>
Subject: Mersenne: What's the right way to do this?
I set up Prime95 on my laptop to get timings for the benchmark page, and it
has started working on 4992583. Sadly, I don't run the laptop 24 hours a
day, the WinModem drivers slow Prime95 down by about a factor 1.5 (0.671
iteration times, as against 0.449), and so it's unlikely that I'll have the
number finished before Christmas.
I have on my desk at home a P2/350, which may well soon become an Athlon/800
given the way Athlon prices are going, which could finish this number within
a week. That machine, however, doesn't have an Internet connection. Can I
just copy the prime95 directory across and let rip, or do I have to do
something to stop prime95 from trying to contact Entropia?
Tom
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 6 Mar 2000 02:06:55 -0800
From: Russel Brooks <[EMAIL PROTECTED]>
Subject: Re: Mersenne: searching the biggies 2
Spike Jones wrote:
> play, there might be some very good reasons to *not* show up
> in the top contributors list. In fact, the someone who organized
What might those reasons be?
Curious...
Russ
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 6 Mar 2000 11:35:03 +0100
From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Bug Report: Wrong timing for Intel Speedstep
You'll have to change the cpu speed in Options/cpu to the correct speed
- -----Original Message-----
From: Hänggi Philipp [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 06, 2000 10:52 AM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: Mersenne: Bug Report: Wrong timing for Intel Speedstep
Hi all
I use a Dell Inspiron 5000 Laptop with the new Intel Speedstep feature.
Which meens that the box runs with 500Mhz on battery and 600Mhz on net power
supply.
My exponet 9066011 is timed with 0.233 secs/iter for 500Mhz and with 0.255
secs/iter for 600Mhz !!!
No, I didn't mix the modes up. But I validated the timing with a stop watch.
The true timings are 0.233 secs/iter for 500Mhz and ~0.200 secs/iter for
600Mhz.
So somethings goes wrong in the calculation of prime95.
By the way, I use windows 98 second release.
Any Ideas ?
Philipp
_________________________________________________________________
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
------------------------------
Date: Mon, 6 Mar 2000 11:56:39 +0100
From: =?ISO-8859-1?Q?H=E4nggi_Philipp?= <[EMAIL PROTECTED]>
Subject: Mersenne: No Bug: Wrong timing for Intel Speedstep
Hi All
Sorry for my bad logic.
If I change the Mhz number in the CPU menue manually, everything is fine.
Thanx for the comments.
Philipp
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 06 Mar 2000 06:43:32 -0500
From: Matthew Temus Smith <[EMAIL PROTECTED]>
Subject: Re: Mersenne: No Bug: Wrong timing for Intel Speedstep
Hänggi Philipp wrote:
> Hi All
>
> Sorry for my bad logic.
>
> If I change the Mhz number in the CPU menue manually, everything is fine.
>
> Thanx for the comments.
>
> Philipp
> _________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
> Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Funny you should have that problem. My main computer is a Pentium III
desktop overclocked to 600MHz. Once I got mprime (that's the Linux client)
to do 9739909 in exactly .200 sec/iter. Now the best I can get is .223
sec/iter. Maybe I have a similar problem. Killing proccesses doesn't seem
to help.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 06 Mar 2000 09:21:14 -0500
From: George Woltman <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Bug Report: Wrong timing for Intel Speedstep
Hi,
At 10:51 AM 3/6/00 +0100, Hänggi Philipp wrote:
>I use a Dell Inspiron 5000 Laptop with the new Intel Speedstep feature.
>Which meens that the box runs with 500Mhz on battery and 600Mhz on net power
>supply.
Try setting "RdtscTiming=0" in prime.ini. This obscure feature is
described in the undoc.txt file.
Regards,
George
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 6 Mar 2000 18:07:44 EST
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: Large-Exponent QA
Ken Kriesel writes:
>Participants in this phase of the QA should be willing to coordinate by
email with
>a partner, running LLtests and double-checks of the same exponent in
parallel,
>and cc George Woltman and myself, interim residues at suitable intervals.
Since you say you also want some non-Intel CPUs to participate her,
I have a couple of comments. An easier way to maintain a running check
of residues is to have the program write a simple Res64 (lower 64 bits
of the residue, in hex form) to a file every few thousand iterations.
Pair up users according to their hardware speed, i.e. so both members
of a QA duo are dispatching iterations for their exponents at roughly
the same speed. Save copies of full-length residue files only every
million iterations or so. If the Res64s for given iteration
match (which needs only a quick exchange of e-mail, once a week or so),
then the full-length files for iterations up to that point don't need to
be compared.
Jason Papadopoulos and I used this approach while testing F24, and it
proved quite convenient. We also did a diff of the final residue of
our respective runs, but had agreed beforehand on a common, platform-
independent savefile format. That is not the case for Prime95 and, e.g.
Mlucas, which is one more reason to use Res64s for at least the on-the-
fly crosschecking (the Mersenne, not hockey, variety :)
Also note that Mlucas starts its iteration counter at 1 rather than 0,
so when Mlucas writes (say) a 2000th-iteration Res64 to the .stat file
for a given exponent, it corresponds to the 1999th-iteration residue
of Prime95. Unfortunately that unit-offset dumbness on my part won't
be fixed until Mlucas 3.0 comes out, because I don't want to deal
with the logistics of figuring out whether a v2.7 savefile was written
by a unit or zer-offset version of the code and figuring out whether
an extra iteration needs to be tacked on before writing the next save-
file. (Mlucas 3.0 savefiles will have a different format, so that won't
be a problem.)
I can easily create a modified QA-only version of the 2.7 code to
use a zero-offset iteration counter, but want to make sure that this
will be part of an agreed-on QA scheme before doing so. George, can
you modify your code to create a QA version that writes periodic
Res64s to a file?
As for which non-x86 hardware would be suitable, here are some
estimated runtime estimates for testing an exponet in various
sample size ranges on the higher-end Alpha, MIPS and Sparc boxes
(all times in CPU-days):
CPU type/cache size: p~20M p~39M p~77M
- -------------------- ----- ----- -----
500MHz Alpha 21264 83d 388d 1782d
64kB L1
4MB L2
400MHz Sparc E450 150d 677d 2763d
32kB L1
4MB L2
300MHz MIPS R12000 137d 609d 2524d
32kB L1
4MB L2
So, it doesn't look like testing exponents above ~40M is going to
be practicable any time soon, where I mean doable in a year or less.
But since the vast majority of GIMPS first-time LL tests won't even
be approaching 20M for some years yet, having one or two double-checked
exponents in each subrange below 39M would seem sufficient for the next
couple of years.
As a lure to prospective QA testers, I say they should be GUARANTEED
p90-CPU-years credit for whatever work they do, assuming they provide
a savefile useable by someone else with compatible hardware if they
choose to drop out before completing an exponent. Requiring them to
complete a really big exponent doesn't allow for all the kinds of
things that can occur during the several years it will take to do
some of these. As long as volunteer Y can pick up where volunteer X
left off, X should get credit for the cycles they contributed.
Cheers,
- -Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 06 Mar 2000 23:35:20 -0500
From: Matthew Temus Smith <[EMAIL PROTECTED]>
Subject: Re: Mersenne: No Bug: Wrong timing for Intel Speedstep
"Brian J. Beesley" wrote:
> On 6 Mar 00, at 6:43, Matthew Temus Smith wrote:
>
> > Funny you should have that problem. My main computer is
a Pentium III
> > desktop overclocked to 600MHz. Once I got mprime
(that's the Linux
> > client) to do 9739909 in exactly .200 sec/iter. Now the
best I can get is
> > .223 sec/iter. Maybe I have a similar problem. Killing
proccesses
> > doesn't seem to help.
>
> Did you change the CPU speed in Options/CPU? The iteration
timing in
> mprime (and Prime95) is calculated from the number of CPU
cycles
> multiplied by the cycle time derived from the CPU speed
entered here.
> If you change the processor speed physically then the
program doesn't
> know... If the iteration timing _in CPU cycles_ changes
without you
> changing the CPU speed, then maybe the memory detection at
boot time
> is inserting extra wait states - because you lost the
NVRAM config,
> or because the memory chips (or chipset) won't take the
faster bus
> without the extra waits.
>
> Regards
> Brian Beesley
Well, my CPU speed is correctly flagged in Options/CPU as
601 and always has
been. I overclocked a long time ago. I don't know about
extra wait states at
boot time or NVRAM config. Is there a way to check this?
Matthew Smith
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 06 Mar 2000 23:09:48 -0600
From: Ken Kriesel <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Large-Exponent QA
At 06:07 PM 3/6/2000 EST, you <[EMAIL PROTECTED]> wrote:
>Ken Kriesel writes:
>
>>Participants in this phase of the QA should be willing to coordinate by
>email with
>>a partner, running LLtests and double-checks of the same exponent in
>parallel,
>>and cc George Woltman and myself, interim residues at suitable intervals.
>
>Since you say you also want some non-Intel CPUs to participate here,
>I have a couple of comments. An easier way to maintain a running check
>of residues is to have the program write a simple Res64 (lower 64 bits
>of the residue, in hex form) to a file every few thousand iterations.
>Pair up users according to their hardware speed, i.e. so both members
>of a QA duo are dispatching iterations for their exponents at roughly
>the same speed. Save copies of full-length residue files only every
>million iterations or so. If the Res64s for given iteration
>match (which needs only a quick exchange of e-mail, once a week or so),
>then the full-length files for iterations up to that point don't need to
>be compared.
What I meant was interim 64-bit residues (not full intermediate savefiles
or full-length residues) every 1 or 2 million iterations, since they will be
compared visually. QAtest volunteers are typically being partnered, and
exchanging just the 64-bit residues by email & cc myself &/or George.
(Keeps the email size much smaller than passing save files, and removes
the temptation of cheating.)
There's no point in the larger traffic of a 64-bit residue every few
thousand iterations, which corresponds to an hour or two of runtime at most.
The QA volunteers are encouraged to keep the full-length intermediate files
of
every million or two million iterations intervals, and do backups, and if
quitting,
transfer the last good save file so someone else can take up where they
leave off.
...
>Also note that Mlucas starts its iteration counter at 1 rather than 0,
>so when Mlucas writes (say) a 2000th-iteration Res64 to the .stat file
>for a given exponent, it corresponds to the 1999th-iteration residue
>of Prime95. Unfortunately that unit-offset dumbness on my part won't
>be fixed until Mlucas 3.0 comes out, because I don't want to deal
>with the logistics of figuring out whether a v2.7 savefile was written
>by a unit or zer-offset version of the code and figuring out whether
>an extra iteration needs to be tacked on before writing the next save-
>file. (Mlucas 3.0 savefiles will have a different format, so that won't
>be a problem.)
>
>I can easily create a modified QA-only version of the 2.7 code to
>use a zero-offset iteration counter, but want to make sure that this
>will be part of an agreed-on QA scheme before doing so. George, can
>you modify your code to create a QA version that writes periodic
>Res64s to a file?
That modification is already present in prime95.
Output looks like this:
[Sun Feb 13 16:51:26 2000]
M4948673 interim residue 06B0A8372B7C3239 at iteration 2000000
[Thu Feb 24 23:45:20 2000]
M4948673 interim residue 7D4B80BF1E9DF827 at iteration 4000000
Lots of results (verified by 2 independent runs on separate processor
generations in V19 prime95) were available at iteration counts of 100 and
400 if I recall correctly, partly for validating future programs, at
ftp://lettuce.edsc.ulst.ac.uk/gimps/PrimeQA/QADATA.TXT
thanks to Brian Beesley for generating the list of exponents to run on,
running most or all of one pass, and hosting the data.
I see that file's no longer there.
The intent of this part of the QA effort was to provide validation of
iteration code on many exponents quickly, both for QA of prime 95 V19,
and future versions of various programs, including the less fast ones,
in all ranges of exponents and runlengths prime95 currently supports.
>So, it doesn't look like testing exponents above ~40M is going to
>be practicable any time soon, where I mean doable in a year or less.
>But since the vast majority of GIMPS first-time LL tests won't even
>be approaching 20M for some years yet, having one or two double-checked
>exponents in each subrange below 39M would seem sufficient for the next
>couple of years.
Remember the 10-mega-digit hunters; there will be exponents above
p=33,000,000 tested before long. Some already have 10M or 12M iterations
done.
QAtesters may play the same hardware-upgrade game as the rank & file,
and upgrading hardware more than once before completing the truly large
exponents is likely. (Last year's fast system was a PII-400; it would take
6.5 years to do p=79,299,xxx; who wants to keep the same workstation
for 6 years?)
>As a lure to prospective QA testers, I say they should be GUARANTEED
>p90-CPU-years credit for whatever work they do, assuming they provide
>a savefile useable by someone else with compatible hardware if they
>choose to drop out before completing an exponent.
I'd like to see them get cpu credit, but I am not in a position to
guarantee it.
Most of the effort would fall on someone else, and I'd rather see George
and Scott doing other things than the bookkeeping of apportioning credit
by iteration count and exponent size and checks of usable save
files. To keep the minimum contribution sizable, I ask the volunteers to
commit to at least a half-PII-400-year; large contributions are more likely
to justify crediting the work or a partial large exponent.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Mon, 06 Mar 2000 21:29:06 -0800
From: Spike Jones <[EMAIL PROTECTED]>
Subject: Mersenne: why stay off the top producers list?
Spike Jones wrote:
> play, there might be some very good reasons to *not* show up
> in the top contributors list. In fact, the someone who organized
Russ asked: What might those reasons be?
Well, if it is a reeeaaaally big company, the contribution of that one
might discourage the individual contributor who, at the end
of the day, is the real backbone of GIMPS, and I hope shall
henceforth be. And those two universities that compete for the
number one spot, I want to see that competition continue, along
with having the students there learn of the game.
What we are doing here is greater than just mapping the great
mathematical universe here, friends. Ask yourself: Do I *know*
more about math now than when I started GIMPS? The vast
majority of us would respond YES! Of course. In this sense
George is perhaps the greatest math teacher of his time, and
furthermore, GIMPS has awakened in many of us a long dormant
love of the beauty and total coolness of mathematics.
Nowthen, I want to *encourage* people to join GIMPS, even
if they have a slow outdated computer, just so more people can
learn some math, have some fun and perhaps spread the meme
that computing is cool.
I am employed at a really big company, and I am trying
to push thru the bureaucracy there to run GIMPS on ALLLL
the computers, 24-7-52. That in itself is a huge job, but it
is a huge prize, all those idle CPUs. Ive been working on
this for almost a year now, and slow progress is being made.
Ive been offered a few machines, but I want em ALL! spike
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Tue, 7 Mar 2000 09:31:48 +0000
From: Alexander Kruppa <[EMAIL PROTECTED]>
Subject: Re: Mersenne: why stay off the top producers list?
Spike Jones wrote:
> Ask yourself: Do I *know*
> more about math now than when I started GIMPS?
You can say that again. I remember well when I asked on the list what the
point of P-1 factoring is when it takes an hour to get to 1000000 (or
1000003, rather) while trial factoring can do 2^40 in the blink of an
eye. Now I feel reasonably comfortable writing a simple P-1 factorer (I
need to get into that polynomial stage 2 thing!), or computing the odds
of finding a factor, given a certain bound.
The best thing I can say about GIMPS is that it revived my long-lost
interest in math, and I'm having a wonderful time with it.
> Ive been offered a few machines, but I want em ALL! spike
Go spike.
Ciao,
Alex.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Tue, 7 Mar 2000 07:23:45 -0700
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: why stay off the top producers list?
> Nowthen, I want to *encourage* people to join GIMPS, even
> if they have a slow outdated computer, just so more people can
> learn some math, have some fun and perhaps spread the meme
> that computing is cool.
>
> I am employed at a really big company, and I am trying
> to push thru the bureaucracy there to run GIMPS on ALLLL
> the computers, 24-7-52. That in itself is a huge job, but it
> is a huge prize, all those idle CPUs. Ive been working on
> this for almost a year now, and slow progress is being made.
> Ive been offered a few machines, but I want em ALL! spike
I'm glad you're doing it the "right" way, compared to the way I did it. :-)
On that note, you might check out the current edition of Science News where
it mentions GIMPS and yes, mentions me. Never mind that Ivars Peterson got
some facts wrong (I was never actually arrested, and US WEST, the FBI and
the US attorneys have lately been backing off on the claim that NTPrime
caused any "slowdown" of the computers), it's still interesting.
http://www.sciencenews.org/20000304/bob1.asp
Aaron
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Tue, 07 Mar 2000 08:43:01 -0600
From: Rich Harms <[EMAIL PROTECTED]>
Subject: Mersenne: PrimeNet error 1 running mprime under Linux
I just set up mprime to run on a Linux (Stampede) box with a Pentium
200 cpu. Every time mprime tries to contact IPS, it receives
"PrimeNet error 1". The internet connection runs through a proxy
server running on a WinNT machine with a dialup modem.
I can switch the network cable from the Linux machine to a Win95
machine which has the same proxy assignment in the primenet.ini file
and the Win95 machine has no trouble communicating with IPS.
What might I be missing?
Rich Harms
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Tue, 7 Mar 2000 19:54:21 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: Large-Exponent QA
On 6 Mar 00, at 23:09, Ken Kriesel wrote:
>
> Lots of results (verified by 2 independent runs on separate processor
> generations in V19 prime95) were available at iteration counts of 100 and
> 400 if I recall correctly, partly for validating future programs, at
> ftp://lettuce.edsc.ulst.ac.uk/gimps/PrimeQA/QADATA.TXT thanks to Brian
> Beesley for generating the list of exponents to run on, running most or
> all of one pass, and hosting the data. I see that file's no longer there.
Actually the file contains the low 64 bits of the residual after 400
and 1000 iterations for smaller exponents (up to 4 million), 400
iterations only for medium size exponents (4 million to 20 million)
and 100 and 400 iterations for larger exponents (20 million to 79
million).
The results were created on an Alpha 21164 using a version of Richard
Crandall's "original" LL testing program lucdwt, modified to write
the interim residual & stop instead of completing the test. It's very
slow compared with the current production software, but much simpler!
I verified the results obtained against both Prime95 v19 on Intel PII
(during beta testing, using both the "classic" and "PPro" tunings of
the FFT code) and Mlucas v2.7z on the Alpha system.
I've just put the file back up. Sorry, it got removed accidentally
when I upgraded the server hardware about three months ago.
[ Ernst Mayer comments ]
> >So, it doesn't look like testing exponents above ~40M is going to
> >be practicable any time soon, where I mean doable in a year or less. But
> >since the vast majority of GIMPS first-time LL tests won't even be
> >approaching 20M for some years yet, having one or two double-checked
> >exponents in each subrange below 39M would seem sufficient for the next
> >couple of years.
I agree. Of course, anyone who thinks it's _fun_ to tie up a system
for several years running a LL test on a larger exponent is quite
welcome to do so, so far as I'm concerned!
> I'd like to see them get cpu credit, but I am not in a position to
> guarantee it.
George seems to add the CPU credit from QA tests to his records. So
far as PrimeNet is concerned, we (deliberately) don't use PrimeNet to
communicate results; in any case PrimeNet doesn't recognize that we
own the QA assignments (some of them are actually triple-checks & the
rest are outside currently active ranges), which is why they "don't
count". This doesn't bother me, but it should be easy enough to fix.
> Most of the effort would fall on someone else, and I'd rather see George
> and Scott doing other things than the bookkeeping of apportioning credit
> by iteration count and exponent size and checks of usable save files. To
> keep the minimum contribution sizable, I ask the volunteers to commit to
> at least a half-PII-400-year; large contributions are more likely to
> justify crediting the work or a partial large exponent.
>
I'd strongly reccomend anyone running PrimeNet 10 million digit
assignments to place the following line in their prime.ini file:
InterimFiles=1000000
This will cause the interim residual to be written to results.txt
every 1000000 iterations. At the same time, an extra save file will
be written. The idea is that, when double-checking is scheduled on
this exponent, any error can be found without neccessarily having to
complete the whole run to find it, thus saving time. Also, in the
event that a prime is found, with a set of interim save files we will
be able to verify the result much more quickly by running 1000000
iterations on thirty odd systems in parallel.
If you're worried about disk space, delete the extra save files; the
interim residual has considerable value in itself.
Also could anyone dropping out of a large exponent run (including
PrimeNet 10 million digit range assignments) please send in a copy of
their last savefile, so that work completed isn't lost. My server has
lots of space available for this task.
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, 8 Mar 2000 00:37:36 -0000
From: "Ian L McLoughlin" <[EMAIL PROTECTED]>
Subject: Mersenne: time and credit...
Well.....
been doing an LL on 9xxxxxx since er....July last year...
on a cyrix333 with Win 98....
Must admit...I'll probably be looking at factorising in
future...yawn....even if I don't get the kudos...
Ian...
double checking has no cache value...lol...
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Tue, 07 Mar 2000 18:05:43 -0800
From: Spike Jones <[EMAIL PROTECTED]>
Subject: Re: Mersenne: why stay off the top producers list?
> > Ive been offered a few machines, but I want em ALL! spike
> Aaron Blosser wrote:
> I'm glad you're doing it the "right" way, compared to the way I did it. :-)
> http://www.sciencenews.org/20000304/bob1.asp
Aaron, its *because* of your experience that I am going the
slow legal way. {8-] Otherwise I mighta just sent out GIMPS
as an enclosure and thought little of it. I never did really get much
management attention until I pointed out that a clever programmer
could *already be using* spare CPU cycles on our machines and
we wouldnt even know it, unless we had our own, well controlled
background process to keep tabs on that.
Those of you who work in big companies, feel free to give your
IT manager a few sleepless nights with that line of reasoning, then
hand her your clever solution... {8^D spike
_________________________________________________________________
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 #703
******************************
