Mersenne Digest Sunday, April 11 1999 Volume 01 : Number 543
----------------------------------------------------------------------
Date: Thu, 8 Apr 1999 17:27:19 -0700
From: "Gilmore, John (AZ75)" <[EMAIL PROTECTED]>
Subject: Mersenne: Request for Software
Anyone have an executable that runs under SGI Irix 6.5 I can use for
double-checking and acquire via FTP or e-mail attachment?
John Gilmore
Not the one from EFF.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Thu, 08 Apr 1999 20:15:57 -0400
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: Mersenne Digest V1 #542
> Does anyone know if NFSNet is still operational and if they
>have a web site? I've had two people ask in the last week.
I don't know, but it's a shame if they're not. I enjoyed being a part
of NFSNet.
As LL tests begin to go beyond the limits of older machines, now may
be a good time to consider a distributed factoring effort. I've wanted
to see one for a while now but frankly, implementing many of the
algorithms is over my head. That, and the lack of a permanent home
have made me shelf it. If, however, anyone wants to talk about
donating code or a server, I don't see why we couldn't make one, and
factor some of the unfinished mersennes.
In my mind, the v17 bug illustrates how important factoring is. It
provides an easily-verified proof of compositeness.
>I recently dicovered all of the web sites I host are blocked by
>SurfWatch.
This is very strange, but it may be an accident. For example, my isp
somehow made a "spammer list" once, and I still occasionally have
problems because of it.
>Those won't last long, I'm sure. I got about eight people to join and less
>than half are still crunching for primenet. Oh well, even one is a good
>thing.
I personally own one machine, a pentium 166. Last time I looked, I was
also 65th on the ips top producers, due entirely to founding a team
and recruiting people. Basically, neither the prize, nor the bug seem
to have had very much effect on the team overall, but almost everyone
got "hooked" after a while and began leaving their machines on a
little longer, asking more questions, etc.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Thu, 8 Apr 1999 18:57:32 -0700
From: Will Edgington <[EMAIL PROTECTED]>
Subject: Mersenne: Factoring & bugs
[EMAIL PROTECTED] writes:
As LL tests begin to go beyond the limits of older machines, now may
be a good time to consider a distributed factoring effort. I've wanted
to see one for a while now but frankly, implementing many of the
algorithms is over my head. That, and the lack of a permanent home
have made me shelf it. If, however, anyone wants to talk about
donating code or a server, I don't see why we couldn't make one, and
factor some of the unfinished mersennes.
See ECMNet. I'm pretty sure there's a link off www.mersenne.org and
off my mersenne.html. There's a new server/client setup that's
apparently almost as automatic as Prime95/PrimeNet. (I haven't had
time to try it yet). But note that ECMNet is trying to completely
factor various numbers, including the Mersennes with exponents into
the low thousands; it is not trying to find factors of the Mersenne
numbers that GIMPS is interested in. If you want to do the latter,
use Prime95.
In my mind, the v17 bug illustrates how important factoring is. It
provides an easily-verified proof of compositeness.
Yes, and that's the whole reason there is a factorer part of GIMPS:
because having it eliminates possibilities faster, and with no need
for a doublecheck. Factors are very easy to confirm; my 200MHz
Pentium can probably verify every known factor in a day or three (and
I have had it do so a few times in the past).
But Prime95's factoring code has also had bugs at times; a bug-free
program is - as I'm sure most of us are aware - effectively
impossible. Which is part of why there are other programs that do the
same things, like the mers package that I maintain. Prior bugs in the
mers package LL testers and factorers were exposed by comparisons with
output from Prime95, just as prior bugs in Prime95 were exposed by
comparisons with the mers package programs.
Will
http://www.garlic.com/~wedgingt/mersenne.html
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Thu, 08 Apr 1999 22:39:23 -0400
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: Factoring & bugs
In message <[EMAIL PROTECTED]>, Will Edgington writes:
>See ECMNet. I'm pretty sure there's a link off www.mersenne.org and
>off my mersenne.html. There's a new server/client setup that's
>apparently almost as automatic as Prime95/PrimeNet. (I haven't had
>time to try it yet). But note that ECMNet is trying to completely
>factor various numbers, including the Mersennes with exponents into
>the low thousands; it is not trying to find factors of the Mersenne
>numbers that GIMPS is interested in. If you want to do the latter,
>use Prime95.
I didn't know they had anything automated. That's a big plus for them.
The problem with ECMNet is ECM. Although it's a useful tool, after a
point it becomes useless. NFSNet, was one of the only large-scale SNFS
efforts, and made excellent progress filling in the Cunningham
Tables.
Perhaps I should have been more clear. What I think we need is more of
a "clearing house" approach, with a client/server relationship
employing probabalistic and guaranteed methods to factor numbers in
the minimum time.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 00:21:35 -0400
From: Joth Tupper <[EMAIL PROTECTED]>
Subject: Mersenne: Question & Suggestion
This pair of items is aimed more or less at George.
1) I run prime95 on my laptop (266 P-II with 64MB RAM). It is probably my
fastest machine for prime95.
However, if I unplug it and let prime95 run, my battery drains in about 1/4
the time (or less) it takes with prime95 stopped.
Is there a way for prime95 to check to see if external power is in use? I
suspect that Win98 supports a call like this.
So far I have not looked into the APIs to see what might be available. As
a suggestion, assuming a call exists, we
might have a new option: suspend prime95 when on battery? with options yes
(at first detection), no (user must do it
manually if user wants to stop prime95 == the same as now, of course), and
ask. On yes and ask, the program must
check for battery power or not. If yes, then stop like {File|Stop} with a
message in the prime95 window.
A suitable time to ask about continuing is when backup files get saved.
On ask, a message box should pop up with a yes/no choice for stop or
continue. There choice could be three choices:
continue and do not ask again this session, continue and ask at next save,
stop.
2) I have had a lot of internet hassles over the past two weeks. This has
turned into a need to reboot a Win98 desktop
frequently because of software crashes of one sort or another.
Something caused an error in prime95: sumout != suminputs. Previously,
this error has just caused prime95 to back up a few hundred iterations from
a save file. Today, prime95 crashed. Several times. I think that all of
the crashes may have been caused
by the same set of events following the sumout error. prime95 attempted to
contact primenet immediately after the sumout error. As I was not
currently logged on, a DUN connectoid popped up. I cancelled the
connectoid and prime95 crashed pretty fatally in
a dll (I goofed: I did not write down the name of the dll and did not save
the crash data ... rpdc.dll??) I ended up rebooting and cancelled the DUN
connectoids that popped and prime95 kept crashing. Finally, I let a DUN
connection go through and prime95 stopped crashing, backed up a few hundred
iterations and seems to be running properly again.
This is probably old news to lots of people, but I wanted to pass it along
in case others are getting hit by it.
Thanks,
Joth
T
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Thu, 8 Apr 1999 22:57:21 -0600
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Question & Suggestion
> From: Joth Tupper
<snip>
> As I was not
> currently logged on, a DUN connectoid popped up. I cancelled the
> connectoid and prime95 crashed pretty fatally in
> a dll (I goofed: I did not write down the name of the dll and
> did not save
> the crash data ... rpdc.dll??)
This sounds like the rpcnet.dll problem. I run it on my laptop and even
when I'm not connected, Prime95 will gracefully continue even when it can't
contact the Primenet server.
On my desktop machines though, when it tries to contact Primenet and can't I
always get the rpcnet.dll error.
Well, it's easy enough to fix. Switch to use HTTP instead of RPC. I've
noticed that HTTP is faster both when timing out and when connecting, so
it's just as well to leave it set at that.
Used to be (if I recall) that RPC was the only way to talk to Primenet, but
since many firewalls block it, HTTP was developed. Forgive me if I'm
destroying the history of Primenet, Scott. :-)
Perhaps it's time to retire RPC or fix the problems. Maybe a "feeler" could
be sent to see if the network is active and if not, cancel the attempt to
connect, just as a kluge around the bug.
> This is probably old news to lots of people, but I wanted to pass it along
> in case others are getting hit by it.
It has been mentioned before, but I didn't remember it until it happened.
Aaron
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 09 Apr 1999 11:36:27 +0200
From: Cyril Flaig <[EMAIL PROTECTED]>
Subject: Mersenne: Search for a prove
Hi all,
I''m searching a prove of a little problem.
You take a four digit number where not all digits are equal such 5957 and
reorder the digits
such that the biggest digit is at the first place, the second at the second
place etc.
Then subtract the smallest possible reoredering from the the other number
and restart the process.
As result you will get 6174.
Example: 5957
9755-5579=4176; 7641-1467=6174; 7641-1467=6174
If you take a five digit number, the result will be a period of 74943,
62964, 71973, 83952.
With six digits it will be a period too.
Have anyone got a prove tor that?
regards
Cyril
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 01:47:17 -0700
From: Paul Leyland <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Re: Factoring & bugs
> I didn't know they had anything automated. That's a big plus for them.
Yes, and very smoothly it runs as well. I'm hosting the master server. I
also run sub-servers (one a slave to the master, another on my network at
home which is entirely independent) which are ideal for division of labour
and the ability to perform private projects rather than requesting tasks
from the main project.
The URLs you want are http://www.loria.fr/~zimmerma/records/ecmnet.html for
ECMNET in general and http://www.interlog.com/~tcharron/ecm.html for the
automatic client/server approach.
> The problem with ECMNet is ECM. Although it's a useful tool, after a
> point it becomes useless. NFSNet, was one of the only large-scale SNFS
> efforts, and made excellent progress filling in the Cunningham
> Tables.
The problem with GIMPS is the LL test. Although it's a useful tool, after a
point it becomes useless. Nonetheless, it is making excellent progress in
filling in tables of Mersenne primes.
You are merely restating a law of nature. After a point, everything becomes
useless. ECM is excellent at finding reasonably large factors of numbers of
a reasonable size --- let's say 40 digit factors of integers of a few
thousand digits or less. NFS is completely useless if we want to factor
integers of only 300 digits. On the other hand, if ECM can nibble away
enough digits by finding small factors, the co-factor can be brought in
range of NFS or similar algorithms such as MPQS. This has happened many
times during the history of the Cunningham project.
> Perhaps I should have been more clear. What I think we need is more of
> a "clearing house" approach, with a client/server relationship
> employing probabalistic and guaranteed methods to factor numbers in
> the minimum time.
ECMNET gives you the first (probabalistic) of those. Admittedly, the second
isn't really implemented yet, though we came very close with the RSA-129 and
RSA-130 projects. The number theory code already exists in various forms.
If someone wants to spend a few weeks writing a c/s harness for it ....
Paul
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 07:44:17 -0400
From: Joth Tupper <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Question & Suggestion
Aaron,
That sure sounds simple enough. Now I just have to determine if the
sumouts I am suddenly seeing
are really hardware. Hmmm.
Thanks,
Joth
Message text written by "Aaron Blosser"
>
Well, it's easy enough to fix. Switch to use HTTP instead of RPC. I've
noticed that HTTP is faster both when timing out and when connecting, so
it's just as well to leave it set at that.
<
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 07:44:17 -0400
From: Joth Tupper <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Question & Suggestion
Aaron,
That sure sounds simple enough. Now I just have to determine if the
sumouts I am suddenly seeing
are really hardware. Hmmm.
Thanks,
Joth
Message text written by "Aaron Blosser"
>
Well, it's easy enough to fix. Switch to use HTTP instead of RPC. I've
noticed that HTTP is faster both when timing out and when connecting, so
it's just as well to leave it set at that.
<
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 09 Apr 1999 02:05:23 -0400
From: Pierre Abbat <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Question & Suggestion
I haven't tried running mprime on a laptop, but I have run another
number-crunching program, and the fan runs continuously and it gets quite
warm.
To find whether the laptop is plugged in, type "cat /proc/apm". If you get "No
such file or directory", and you are running on a laptop, you need to
recompile your kernel. I get that error on the desktop, which is running
mprime, but the laptop has the file, and I get the following:
With the laptop plugged in:
1.2 1.1 0x03 0x01 0x00 0x01 100% -1 ?
With it unplugged:
1.2 1.1 0x03 0x00 0x00 0x01 98% 220 min
The fourth word appears to indicate whether the laptop is plugged in.
Immediately after unplugging the laptop, you may read "-1%" from /proc/apm .
If this happens, wait a minute and try again.
This is a very good suggestion and I look forward to seeing it implemented.
phma
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 11:47:08 -0300 (EST)
From: Marc Thibeault <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Question & Suggestion
On Thu, 8 Apr 1999, Aaron Blosser wrote:
I just hope that RPC will stay because for the computers
that I have connected to Primenet here, http does not work; I get a
message error. I do not know why and do not care since RPC work so well !!
Marc Thibeault
>
...
> Perhaps it's time to retire RPC or fix the problems. Maybe a "feeler" could
> be sent to see if the network is active and if not, cancel the attempt to
> connect, just as a kluge around the bug.
>
> Aaron
>
> ________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
>
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 19:44:52 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: rpcnet
To stop Prime95 Ver 18 from crashing while not connected to the Internet, I
have to use rcpnet.dll from Ver 17. I never had any problem until Ver 18.
James Griffin
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 9 Apr 1999 18:19:12 -0600
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: rpcnet
> From: [EMAIL PROTECTED]
> To stop Prime95 Ver 18 from crashing while not connected to the
> Internet, I
> have to use rcpnet.dll from Ver 17. I never had any problem until Ver 18.
>
> James Griffin
Hmmm..well...
I take it back. Leave RPCNET.DLL in then :-)
I had problems with RPC in v17 and v18 where it would crash when contacting
Primenet and no network connection was detected.
The big problem, I noticed, were machines with network cards that will
refuse to start when no network cable is connected, such as the Intel E100B
cards.
Other NIC's like those from 3Com will still initialize if no network link is
found, and when a connection is attempted, RPC doesn't crash.
Maybe for some of you folks, HTTP is doing the same thing?
My laptop for instance uses a 3Com PCMCIA card and doesn't crash with RPC,
but other laptops I've seen with other PC cards do crash with the RPC
(sorry...I forgot what brand those cards were...Xircom or Megahertz maybe?)
But it seems to only affect NIC's that see a broken network link and shut
themselves down.
You can tell if your network card does this...
If your Windows 95/98 machine is set to logon to a domain and normally stops
to ask for a password, even with no network cable plugged in, your card
doesn't care.
If your machine boots and skips right past the logon prompt when no cable is
connected, your network card deactivated itself and Windows didn't see any
reason to bother having you logon since there's no network. Normally with
NIC's like that, you need to reboot the machine after plugging in the
network cable in order to see anything. Really annoying. That's why I'll
stick with 3Com cards, thank you very much. :-)
Just my network engineering mode kicking in. I so rarely get to comment on
cool algorithms for LL tests, so this is my way of contributing to the cause
:-)
Aaron
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 09 Apr 1999 22:57:50 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Re: Mersenne: preventive measures
Hi all,
At 04:56 PM 4/3/99 -0600, Ken Kriesel wrote:
>Since we now have a wealth of exponents to be tested or retested,
>requiring a total expenditure of billions of cpu-hours, perhaps
>we could introduce a little more formalism into the program-validation
>process. I volunteered months ago to test 1 or 2 exponents in each
runlength.
>Several have completed. Brian Beesley offered to double-check my
>results, and George has assigned them to Brian as double-checks.
>The nature of the just-discovered bug suggests that more test cases are
>in order.
>
>I propose the following be considered, for each future version released
>(and for the versions in heavy use currently):
>1. Code review by qualified volunteers.
A good idea for the C code, I doubt the assembly code qualifies.
>2. George and such other people as are qualified, determine which exponents
>make good test cases, based on a review of the code.
My input:
1) Those near the end of each range should be checked for
excessive convolution error. In fact, it would be nice it the QA
suite recommended the crossover points for the FFTs.
2) Exponents that are close to a multiple of the FFT length.
Crandall's "magic numbers" are very sensitive here.
>3. Volunteers with some cpu-power run LLtests and double-checks on the test
>cases selected.
As pointed out earlier, a few hundred iterations *should* suffice.
But Ken may decide a few more lengthy checks are required.
And as v17 pointed out, the shifting code needs to be checked
in the above tests.
>Since this project is in a sense George's baby, I feel he has the right
>to ok or nix this. If he says ok, I volunteer to be the contact point
>for volunteers to enlist as either code reviewers, testers, or both.
>After a week or two I will summarize to George.
OK, I never turn down a volunteer! I hereby appint Ken the coordinator
of the official GIMPS QA project.
First order of business is a plan of action - formulating the QA test suite.
How much CPU power are we going to require? Would enough tests to keep
5 volunteers busy for 24 hours suffice? Will the ports run shorter suites?
This QA suite will not be my baby, so don't be shy folks in chiming
in with ideas or offering to help Ken out. I'll put in whatever hooks
you folks need.
Now for some good news-------->
Prime95 v19 is under way. It involves rewriting ALL the FFT code!
So this QA project is quite timely.
What's new in v19? It should support FFT lengths from 32 up to 4M
with PFA lengths (3*power-of-two and 5*power-of-two) supported.
It has a slightly modified memory model that should be more efficient in
using the Pentium's TLB (translation look-aside buffers) cache for
larger FFT sizes. A little less memory traffic for some FFT lengths.
P-1 factoring support.
What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n)
GCD to make P-1 and ECM factoring on larger exponents feasible. A more
memory efficient but slower stage 2 for large exponents. Several FFT sizes
are not coded yet. Obviously, don't expect v19 anytime soon!
Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster.
Oh, and by the way, the re-engineered assembly code will be easily usable
in other large integer programs.
Best regards,
George
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Fri, 09 Apr 1999 22:34:29 -0500
From: [EMAIL PROTECTED] (Mikus Grinbergs)
Subject: Re: Mersenne: preventive measures
>
> First order of business is a plan of action - formulating the QA test suite.
Something that is already built-in to 'mprime' is the self-test.
Could the QA people please investigate adding another test-suite
(or updating the old one) so that people on other platforms (i.e.,
people who are running a port of 'mprime' rather than the original
'mprime' itself, or maybe even people who have *changed* the code
for a non-Intel chip) could run that test-suite and be reasonably
sure that their hardware/software combo *is* working properly.
> How much CPU power are we going to require? Would enough tests to keep
> 5 volunteers busy for 24 hours suffice?
Let's assume that new versions of 'mprime' will take more than
three months to create. Then what is being validated by a QA
suite is the ability to run productively for 100+ days. Surely
24 hours is *not* too much overhead, if confidence is gained.
mikus
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sat, 10 Apr 1999 08:41:16 -0600
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: preventive measures
> From: George Woltman
> Now for some good news-------->
>
> Prime95 v19 is under way. It involves rewriting ALL the FFT code!
> So this QA project is quite timely.
>
> What's new in v19? It should support FFT lengths from 32 up to 4M
> with PFA lengths (3*power-of-two and 5*power-of-two) supported.
> It has a slightly modified memory model that should be more efficient in
> using the Pentium's TLB (translation look-aside buffers) cache for
> larger FFT sizes. A little less memory traffic for some FFT lengths.
> P-1 factoring support.
>
> What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n)
> GCD to make P-1 and ECM factoring on larger exponents feasible. A more
> memory efficient but slower stage 2 for large exponents. Several
> FFT sizes
> are not coded yet. Obviously, don't expect v19 anytime soon!
>
> Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster.
>
> Oh, and by the way, the re-engineered assembly code will be easily usable
> in other large integer programs.
George...is it too late to request features for the new version?
I had done some thinking on it, and wouldn't it be great if there were some
sort of "live update" feature, where it could upgrade itself when new
versions come out. That's pie in the sky and I remember discussing
previously how that wouldn't work for everyone - security issues, bandwidth
issues, etc. but perhaps if it were an option.
At the very least, I think that there should be an "alert" or other
notification of some sort when a new version comes out, rather than relying
on emails being sent. The problems with version 17 should give a good
example of how that would help. A problem is found with a version, or
simply a new faster version is out, so the next time Prime contacts
Primenet, it sees some flag set and pops up a box on the screen telling the
user about the new version. And a seperate option for how often to check
for "messages" besides the number of days between checking in at primenet to
update expected completion dates.
Also, do you plan to optimize the assembly code in any way for the new types
of CPU's out? AMD's K6-3, Pentium III, etc. It would certainly "seem" that
some slight tweaking could be done to squeeze out a few extra percent of
improvement, but I could only guess at that. Maybe just recompiling the
assembly in a compiler that is PIII/K63 aware would take advantage of the
processor type, and then just include each compilation in the program with
the appropriate branches into the code depending on the CPU type actually
being used, just as you have now for PPro/PII, Pentium, etc.
One other thing that is, perhaps more pie in the sky, but central
configuration for a team. What I mean is, for all my computers, I generally
have them set the same in terms of days between check ins, minutes between
retries, etc. If I ever need to change some setting, I have to go to each
machine (over the network at least) and change each instance. I thought
it'd be nice if there were a feature where you could set some configuration
to point to a local network share that contains the latest "master" copy of
the prime.ini file. Each time the program starts, it would check the master
for any changes, or continue with the existing INI file if the master isn't
reachable or if no changes were found. Or maybe have it check it on a
regular, adjustable schedule.
Oh yes, I thought of one more thing. Currently, things like affinity and
the service names for NTPrime are located in the PRIME.INI file. Since
those are more peculiar to the instance running, I thought that perhaps
those options would be better suited in the local.ini file. Reason being, I
have several quad processor machines and I have to modify not only local.ini
to set the "computerid" but also prime.ini for each instance to set a unique
service name and affinity. Wouldn't it be better to have just a single,
unchanged prime.ini for each one and only have a unique local.ini that has
all the changeable info in it? That makes the idea of a centralized
prime.ini that much better/easier.
Thats all. For now. :-)
Aaron
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sat, 10 Apr 1999 17:40:23 +0200
From: Henk Stokhorst <[EMAIL PROTECTED]>
Subject: Re: Mersenne: preventive measures
Aaron Blosser wrote:
> > From: George Woltman
>
> > Now for some good news-------->
> >
> > Prime95 v19 is under way. It involves rewriting ALL the FFT code!
Hmm, I know it would take a few resources, but a windows look and feel, instead
of typed lines, with a little more info on progress etc. Simple charts, just for
the fun, in case there is nothing else useful to be done.
Henk Stokhorst
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sun, 11 Apr 1999 12:46:26 -0500
From: Ken Kriesel <[EMAIL PROTECTED]>
Subject: RE: Mersenne: preventive measures
At 08:41 AM 1999/04/10 -0600, "Aaron Blosser" <[EMAIL PROTECTED]> wrote:
>George...is it too late to request features for the new version?
>
>I had done some thinking on it, and wouldn't it be great if there were some
>sort of "live update" feature, where it could upgrade itself when new
>versions come out. That's pie in the sky and I remember discussing
>previously how that wouldn't work for everyone - security issues, bandwidth
>issues, etc. but perhaps if it were an option.
This feature would have meant that V17 shift count bug would have cost
the project more cpu years than it did. In my case, its impact is a
little under 1 cpu year (one exponent in the 10.5M area) because most
processors I'm running were at older versions.
There is a publicly available service which checks for changes in web pages,
and sends email when a checked page changes. I think Internet Explorer
V5 supports some sort of favorite-page-change detection too.
This combined with being able to remotely stop an NT service and deposit
updated files from a batch procedure on one workstation makes managing
large numbers of workstations practical and quick.
>At the very least, I think that there should be an "alert" or other
>notification of some sort when a new version comes out, rather than relying
>on emails being sent. The problems with version 17 should give a good
>example of how that would help. A problem is found with a version, or
>simply a new faster version is out, so the next time Prime contacts
>Primenet, it sees some flag set and pops up a box on the screen telling the
>user about the new version. And a seperate option for how often to check
>for "messages" besides the number of days between checking in at primenet to
>update expected completion dates.
I would find a popup box a terrible nuisance, so I'd like an option
to turn it off or on, with default off.
The feature I'd like to see at some point is the LLtest code made dual-cpu
aware, splitting the load so one cpu does one half of the run-length and
the other cpu does the other half, so that the onboard and on-chip caches
would be more efficiently used, and total working set smaller, and exponents
completed more quickly. I have a dual-pentium 200 MMX that isn't terribly
fast when running two prime95 instances on exponents above 10^7. The
performance on the dual-pentium or dual-ppro systems I have access to is,
when running two instances, about 1.6 times that of running 1 instance.
So there is some room for improvement. On this setup, there are 2 L1 caches,
but one L2 cache being shared by two prime95 instances.
Ken
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
End of Mersenne Digest V1 #543
******************************
