Mersenne: Re: Your rude Mersenne post

1999-10-11 Thread Steinar H . Gunderson

On Sun, Oct 10, 1999 at 06:16:15PM (name deleted) wrote:
I think you were extremely rude and should apologize.

I did not mean to sound rude. If I sounded rude, I _do_ apologize -- it was
not my intention at all.

Again, please accept my apologies.

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



Mersenne: change of PC

1999-10-11 Thread Grieken, Paul van

Members,
today I have a new PC on my desk at work.
On the old PC , which was a 100MHz machine, I did double checking.
Now I have a Pentium III at 455MHz.
If I want to change from double checking to LL-testing what do I have to
do, or changes the server the work when he reads it is a faster PC.

Bye,
Paul van Grieken


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



Re: Mersenne: Re: Version 19 Problems/Win 98

1999-10-11 Thread Brian J. Beesley

On 11 Oct 99, at 0:20, Steinar H. Gunderson wrote:

 Surely the EXE. file (Red) is the one...I now after grappling with
 shortcuts and supplanting various files blah blah cant download any work
 that I have managed to salvage from an exponent I have been testing for over
 4 months...
 
 Could you please be a bit more specific here?
 
 Is your problem that the p-file no longer is usable? Did you extract v19
 into a new directory, or the same as v18?

Some of us have done this _lots_ of times on _lots_ of systems  
haven't had any problems. I wonder if the problem is related to 
whatever software the user is unzipping the distribution file with. 
Assuming that instructions to unzip into the same directory (over-
writing the old files) are being obeyed.

v19 is known to be able to read save files from previous versions - 
unless the save file is corrupt - e.g. the system power went down 
whilst the file was being written, or two applications managed to 
write to the file simultaneously (which doesn't sound very likely?)

Of course, it's _always_ wise to back up directories containing "work 
in hand" before upgrading _any_ software, or installing anything new 
... just in case ...
 
 O.K. I downloaded it...Version 19 is no faster than 18
 
 That would probably be because you're using a Cyrix CPU. If you had had a
 Pentium (or a Pentium Pro/II/III), you would definitely have noticed a
 difference :-)

Nah, there's very little difference on a plain Pentium either.
 
 FOR GOD SAKE GIVE ME A USER FRIENDLY INTERFACE, PROPER HELP MENU
 AHH
 
 If you want a help interface, why don't you go off writing one yourself?
 Do the community a service, and never let anybody have to search the text-
 files again...

Constructive criticism is more useful. If you don't like the way 
something works, tell us _exactly_ why, and how you would like it to 
work instead. If an installation goes wrong, tell us _exactly_ 
everything you did, to what  in what order, also details of exact 
version of OS. If we can replicate a problem, we may be able to fix 
it. Given only "it doesn't work", that's a bit hard - when few of us 
seem ever to have seen any similar problem.


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



Re: Mersenne: glitches in mprime v19?

1999-10-11 Thread jason


Well, I also downloaded mprime.tar.gz, and I had a slightly different
problem trying to connect to the PrimeNet server.  To summarize:

mprime.tar.gz v19.0.2:  results in "ERROR: Primenet error 1"
sprime.tar.gz v19.0.2:  results in "Error 2250: Server unavailable"
mprime.tar.gz v18.1.2:  No problems.

I wonder why the two versions give different error messages (and why I'm
getting them at all)?  Anyway, I just compiled mprime from source
(debugging not enabled), and it's working just fine.  Except for the fact
that I will not receive credit for my work, since I compiled it myself...
so much for initiative.  :-)

-jason

(I'm cc:'ing this to the list in case anyone else (besides Walt) is
experiencing this behavior.)


On Mon, 11 Oct 1999, Brian J. Beesley wrote:

 I think most of us who were using the unix betas were using mprime
 rather than sprime. I've run mprime on several systems with both RH 
 5.1 and RH 6.0  it definitely doesn't have the problem. But I can't 
 recall testing sprime against PrimeNet - those of us involved in QA  
 work were instructed specifically _not_ to use the PrimeNet interface
 until fairly recently, since PrimeNet wasn't ready!
 

 Regards
 Brian Beesley


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



Mersenne: is www.mersenne.org broken ?

1999-10-11 Thread Darxus



__
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
[EMAIL PROTECTED] / http://www.op.net/~darxus
  Join the Great Internet Mersenne Prime Search
http://www.mersenne.org/prime.htm


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



Mersenne: Mprime Error 2250

1999-10-11 Thread George Woltman

Hi all,

This info was reported to me.  As a Linux-newbie I have no idea if it
will prove helpful to others.


I've just done a bit of browsing with `strace' on my machine here at
work, at it's looking like a configuration issue.  Running `strace'
on either mprime 19 or the glibc2-linked mprime 18 reveals a slight
difference in hostname lookups compared with the original libc5-linked
mprime 18.  The newer versions consult /etc/nsswitch.conf (exactly as
expected since this was one of the changes with glibc2), while
the
older version consults /etc/host.conf. (I just verified that glibc2
falls thru to use /etc/host.conf if /etc/nsswitch.conf doesn't exist.)

The problem on this system is that /etc/host.conf was specifying
"order hosts" instead of "order hosts,bind".  Making the change now
allows the older mprime to contact the Primenet server.  


Regards,
George

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



Mersenne: Re: Mlucas on MIPS R4600

1999-10-11 Thread EWMAYER

Wojciech Florek [EMAIL PROTECTED] writes:

I've compiled Mlucas 2.7y on R4600 SGI IRIX 6.5 machine with 
MIPSpro Compilers: Version 7.2.1.3m .
Machine data:

   Powered by Silicon Graphics
  
   CPU MIPS R4600 Processor Chip Revision: 2.0
   FPU MIPS R4600 Floating Point Coprocessor Revision: 2.0
   1 133 MHZ IP22 Processor
   Main memory size 128 Mbytes
   Secondary unified instruction/data cache size 512 Kbytes on Processor 0
   Instruction cache size 16 Kbytes
   Data cache size 16 Kbytes

MacLucasUNIX writes checkpoints after each 5000 iterations, what makes
about 2h 20 min (it isn't `clean' CPU time but almost 98% of CPU was 
devoted to MacLucasUNIX), so I've run Mlucas 2.7 for the same exponent and
5000 iterations (MacLucasUNIX was stopped so almost all CPU time was
assigned to Mlucas). Here are the results

 Enter p,n (set n=0 for default FFT length)  3355031,262144 
 Enter 'y' to run a self-test, return for a full LL test  y
 Enter number of iterations for timing test 5000
  p is prime...proceeding with Lucas-Lehmer test...
 M(  3355031 ): using an FFT length of  262144
  this gives an average  12.798427581787109 bits per digit
 INFO: Using real*16 for FFT sincos and DWT weights tables inits.
5000 iterations of M 3355031 with FFT length  262144
 Res64: 6E592176A2A59208. Program: E2.7y
 Clocks = 01:49:34.963

About 30 min faster! 

That's encouraging - now try the same exponents at runlength 192K (196608) -
you should get the same Res64, but your time should be even better.

I've used the options provided in the source file and haven't played
with them.

Make sure you use -r4600 rather than -r1, and -mips{whatever generation
R4600 is, probably 2 or 3) rather than -mips4.

Your timing corresponds to
1.32 sec/iteration, compared to 0.185 sec at 256K for the same code on
a 250MHz MIPS R1 - even after adjusting for the faster clock speed
of the latter and accounting for the fact that the R1 is a more
advanced processor, I think you should be able to get somewhat better
performance out of your R4600. If you do find flags that give better
performance, let me know.

Some remarks:
 1. In the interactive mode entering return instead of `y' causes
a misprint in comments:
 Enter p,n (set n=0 for default FFT length)  
 Enter 'y' to run a self-test, return for a full LL test  
 p is prime...proceeding wit
!!  a line is broken here! It doesn't happen when I replied `y'

That sounds like a compiler error, but there's an easy workaround - for
full LL tests you should be entering exponents into the worktodo.ini
file anyway, and that avoids having to enter any input.

2. For small Mersenne exponents an `exit carry' error occurs. It's
   happened for M787  M797

 M(  797 ): using an FFT length of 512
  this gives an average  1.556640625 bits per digit

 INFO: Using real*16 for FFT sincos and DWT weights tables inits.
 FATAL: iter= 225  nonzero exit carry in radix16_ditN_cy_dif1.

The carry propagation routines in Mlucas assume that any "wraparound" carry
left over when one gets to the most-significant digit of the residue vector
will propagate no further than 4 digits into the low end of the residue,
i.e. that (exit carry) = 2^(4*radix). If you use a very small radix as
in the above the case, this assumption may no longer be true.

I know that these exponents have been tested, but there is a question
whether it may happen for larger mersennes?

There shouldn't be any problem with large exponents ( 5000, say) since
for large p, one always has an available FFT length which is well-
matched to the number in question, i.e. gives  10 bits per digit. 

3. My LL (double checking) tests on IRIX machines with MacLucasUNIX
  are in progress (50% and 75%). I think that there is no possibility
  to switch to Mlucas during tests and starting from the begining

Indeed there is not - if your MLU runs are  25% complete, finish them
using MLU and use Mlucas for subsequent tests.

On the other hand, if you find a greater speed gain using 192K runlength
and/or better compile options, the above 25% breakover threshold will be
increased.

Happy hunting,
-Ernst

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



Re: Mersenne: V19 Bug in Factoring Timing?

1999-10-11 Thread George Woltman

Hi,

At 01:24 PM 10/10/99 -0400, Walt Mankowski wrote:
I just upgraded this morning to the latest Linux version of Linux,
v19.0.2.  The box with the problem is a 486-66 running Red Hat 5.0.
I'm noticing some strange numbers in its output:

Factoring M10533203 to 2^64 is 39.84% complete.  310.630 sec.
Factoring M10533203 to 2^64 is 39.85% complete.  -3984.147 sec.

I have a fix for this.  Look for it in version 19.1 - no release
date yet.

Regards,
George

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



Mersenne: resuming a prime

1999-10-11 Thread Darxus



 prime  fact  current days
exponentbits iteration  run / to go / exp   date updated date
assigned
computer ID
 --  -  -  --- ---  

 8410531 63   116988423.3  30.0  46.0  27-Sep-99 00:53  18-Sep-99 18:08
 8553229 64   6.3  26.8  81.8  06-Oct-99 21:24  05-Oct-99 19:24  WorkPC
 8642303  *  63   0.0  42.0  88.0   12-Oct-99 01:33  HomePC

Okay, I currently have 3 exponents assigned to me.

1st for my home PC, which I did not give a computer ID, and which has
suffered a hard drive crash, and I nolonger have the info for.

2nd for my PC at work

3rd -- just reinstalled the gimps client on my home PC.  How do I tell my
home PC to resume prime exponent 8410531, which it was working on before
the crash ?

__
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
[EMAIL PROTECTED] / http://www.op.net/~darxus
  Join the Great Internet Mersenne Prime Search
http://www.mersenne.org/prime.htm


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



Mersenne: Re: resuming a prime

1999-10-11 Thread Darxus


 3rd -- just reinstalled the gimps client on my home PC.  How do I tell my
 home PC to resume prime exponent 8410531, which it was working on before
 the crash ?

Eww, sorry, found it in the faq.

But actually, since I want to switch to the 10,000,000 digit primes, how
do I release the old ones ?
__
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
[EMAIL PROTECTED] / http://www.op.net/~darxus
  Join the Great Internet Mersenne Prime Search
http://www.mersenne.org/prime.htm


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



Re: Mersenne: Re: GIMPS

1999-10-11 Thread John R Pierce

 RSX-11M-PLUS, Version 4.3  Base level 66   (PDP)

Err, thats a PDP-11.  A old (early/mid 1970s) 16 bit computer with probably
64k-128k of ram.  Instruction cycle time is probably sub 1Mhz. Floating
point was an expensive optional board which was treated like a IO peripheral
on most PDP-11's.

 VAX/VMS V5.5-2 (MicroVAX 3900)

If I recall (could be wrong) this was slower than the VAX-11/780?  If so, we
are talking about a sub-1 MFLOPS 32 bit minicomputer.  You can take the MHz
of a VAX-11 class CPU and divide by about 8-10 to get the MIPS rating.  The
original VAX-11/780 reference model ran at 10MHz or about 1.2MIPS.  On many
of the smaller models, floating point was emulated, hence very slow.

 VAX/VMS A5.5   (Workstation)

Probably also a VAX architecture machine, but not clear which model.

 These computers are doing nothing all the day and they could support
 GIMPS though they are really old.

a year on one of these wouldn't equal one day on a pentium-II.

-jrp


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



RE: Mersenne: resuming a prime

1999-10-11 Thread Aaron Blosser

8410531 63   116988423.3  30.0  46.0  27-Sep-99 00:53  18-Sep-99
18:08

 3rd -- just reinstalled the gimps client on my home PC.  How do I tell my
 home PC to resume prime exponent 8410531, which it was working on before
 the crash ?

Just add a line to the worktodo.ini file (or make it if you haven't started
the GIMPS client yet) that reads:

Test=8410531,63

A doublecheck would look like:

DoubleCheck=exponent,factoredbits

That's all.  The 8410531 is the exponent to test, and the 63 is how many
bits it's already been factored to.  That particular exponent would now be
factored to 64 bits under the v19 client, so if you update the client to
that version, expect it to factor up to 64 bits before starting on the LL
test.

I guess we'll really see how well v19 is doing.  I just switched my machines
over (most of 'em anyway) to v19, all running the NT service version.
Tomorrow I'll try updating the Win98 machines I have with the new prime95.
Harder to do that since I can't do it remotely as easily as with NT boxes.
Someday, Windows 95/98 will be gone and my life will be easier.

So far, all are working well.  And I've got about 7 boxes running Windows
2000 of various builds.  Some Beta 3, some RC1 and some RC2.  A couple
Advanced Server and others are Win2K Professional.  All are running v19 just
fine (and were running v18 just fine also).

Aaron

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