Mersenne Digest         Friday, April 14 2000         Volume 01 : Number 718




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

Date: Wed, 12 Apr 2000 17:39:55 -0700
From: "John R Pierce" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: dell poweredge server

> well, if anyone recalls me getting error: illegal sumouts on this
> new Dell PowerEdge 4400 server, its apparently the ram after all.
>
> I stripped the machine back to the original 256MB it came with
> and the errors have vanished.

whoops, no they haven't.  If I launch X-windows or something while two
mersenne instances are running, it gets ILLEGAL SUMOUT on both instances
within a few seconds.  Uh oh.  sounds like something wrong with the system
architecture.

- -jrp



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

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

Date: Wed, 12 Apr 2000 20:35:02 -0700
From: "John R Pierce" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: dell poweredge server and Linux SMP.

John R Pierce wrote:
 >whoops, no they haven't.  If I launch X-windows or something while two
 >mersenne instances are running, it gets ILLEGAL SUMOUT on both instances
 >within a few seconds.  Uh oh.  sounds like something wrong with the system
 >architecture.

George Woltman answers...

> not necessarily.  In Windows, ILLEGAL SUMOUTS often occur from
> drivers or the OS not saving FPU state properly.  Maybe Linux has the
> same trouble.  If you don't start to get the other error types, I'd
suspect so.


Ok, then a question for the group at large...  Anyone else running 2
instances of mprime on linux on any sort of dual PPro/P-II/P-III/Xeon
system?  Using something along the lines of 2.2.13ish (This is a Redhat 6.1
"SBE" edition).  Anyone see Illegal Sumouts when they do things like startx
then stopx or maybe change display modes?   For what its worth, this
particular system has a ATI Rage128 onboard and is using XF86_SVGA 3.3.6.

- -jrp


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

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

Date: Wed, 12 Apr 2000 23:53:02 -0400
From: Eric Bravick <[EMAIL PROTECTED]>
Subject: Mersenne: SPARC/Solaris client

Is anyone actually working on the SPARC/Solaris client?  I've seen it
under "coming soon" ever since I joined the effort.  Speaking as someone
with a bunch of SPARC CPU's sitting around doing (almost) nothing, I'm
kind of interested in seeing this port...

Thanks.

- -- 
- --------------------------------------------------
- --   Eric Bravick, Engineering Shock Trooper    --
- ---       Networked Knowledge Systems          ---      
- ----   P.O. Box 20772 Tampa, FL. 33622-0772   ----
- ------          [EMAIL PROTECTED]            ------
- --------------------------------------------------
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

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

Date: Thu, 13 Apr 2000 07:34:17 +0200
From: Martijn Kruithof <[EMAIL PROTECTED]>
Subject: Re: Mersenne: V20 beta #4 (will the beta never end?)

Hello all,

This happened on my machine while switching from beta 3 to beta 4 is
this correct?

Starting P-1 factoring on M33237229 with B1=330000, B2=2640000
Chance of finding a factor is an estimated 4.08%
P-1 on M33237229 with B1=330000, B2=2640000
M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292
clocks)

And after installing beta 4: (Stage 1 was not redone!)

Starting P-1 factoring on M33237229 with B1=305000, B2=1525000
Chance of finding a factor is an estimated 3.58%
P-1 on M33237229 with B1=305000, B2=1525000
M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179
clocks) 


Furthermore a feature would be very nice that it does not recalculate
the bounds 
without the users consent. (even if it violates the memory bounds)

The way to run the memory constraints on a dual machine is by the way
configuring
day/nighttime differently for the two cpu's as the stage 2 is only very
short, it does
not matter if that's only 4 hours (it can resume the next day anyway).
(i.e.) one has daytime from 6 pm to 6 am, the other from 6 am to 6 pm.
(real daytime from 19 to 23 pm might yield : daytime from 19 to 6 and
one daytime from 6 to 23)


Kind Regards, Martijn


George Woltman wrote:
> 
> Hi all,
> 
> The fourth beta is available.  It fixes a few more bugs.  See the
> whatsnew.txt at the end of this email.  An upgrade from earlier betas
> is not required, but it can't hurt.
> 
> You can download it from
> ftp://entropia.com/gimps/v20/p95setup.exe
> or
> ftp://entropia.com/gimps/v20/prime95.zip
> or
> ftp://entropia.com/gimps/v20/mprime.tgz
> or
> ftp://entropia.com/gimps/v20/sprime.tgz
> 
> Regards,
> George
> 
> 1)  Another fairly uncommon ECM bug was fixed.  The bug caused "Factor does
>      not divide N!" errors.
> 2)  A couple of minor bugs in computing the optimal P-1 bounds to use prior
>      to a Lucas-Lehmer test were fixed.  The program now does a better job at
>      estimating the memory required in P-1 stage 2.  Finally, although P-1
>      stage 2 working set size is unchanged, the program allocates less memory
>      in stage 2.
> 3)  Prime95 no longer searches for a smaller factor when trial factoring
>      discovers a factor.  The reasons are two-fold.  1)  Version 19 had a
>      bug where stopping and restarting the program bypassed the search for
>      smaller factors.  Thus, my database may already be missing smaller
>      factors.  2) As we factor larger exponents to a deeper depth it may
>      no longer be a quick job to determine if there are smaller factors.
>      Note, that version 20 will still look for smaller factors if you are
>      looking for factors below 2^60 with the FactorOverride option in
> undoc.txt.
> 4)  The undocumented AMPM feature controls how times are formatted in the
>      Options/CPU dialog box.
> 
> _________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
> Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

- -- 
http://jkf.penguinpowered.com
Linux distributies voor maar
Fl 10 per CD, inclusief verzendkosten!
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

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

Date: Thu, 13 Apr 2000 00:23:49 -0700
From: Will Edgington <[EMAIL PROTECTED]>
Subject: Mersenne: SPARC/Solaris client

Eric Bravick writes:

   Is anyone actually working on the SPARC/Solaris client?  I've seen
   it under "coming soon" ever since I joined the effort.  Speaking as
   someone with a bunch of SPARC CPU's sitting around doing (almost)
   nothing, I'm kind of interested in seeing this port...

Yes, a lot of people are waiting quite patiently.  Unfortunately, I
have not had enough time, partly - but nowhere near entirely - because
I don't have access to a SPARC any more.

But, since you don't say what kind of client, I'll point out that
there are LL test and factoring programs out there that run on SPARCs;
the only current lack is automatic PrimeNet support.  Using PrimeNet's
manual test pages is quite feasible.

                                                        Will

http://www.garlic.com/~wedgingt/mersenne.html  Mersenne info & links
                                mers.tgz       Mers package (C software)
                                mers.zip       Zip'd instead of tar'd & gzip'd
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

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

Date: Thu, 13 Apr 2000 09:25:07 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: dell poweredge server and Linux SMP.

On 12 Apr 00, at 20:35, John R Pierce wrote:

> Ok, then a question for the group at large...  Anyone else running 2
> instances of mprime on linux on any sort of dual PPro/P-II/P-III/Xeon
> system?  Using something along the lines of 2.2.13ish (This is a Redhat
> 6.1 "SBE" edition).

Yep. Two instances of mprime installed in seperate directories. 
System is dual PII-350 in a Supermicro P6DBS board running kernel 
2.2.12-20smp (straight from the Red Hat 6.1 CD). As a matter of 
principle I run these under a normal user account, not root, and use 
"nice -n20" to control the job priority.

>  Anyone see Illegal Sumouts when they do things like
> startx then stopx or maybe change display modes?   For what its worth,
> this particular system has a ATI Rage128 onboard and is using XF86_SVGA
> 3.3.6.

Nope. Starting/stopping/reconfiguring X has no effect except to make 
the mprime processes run more slowly. My system has an ATI Xpert@Work 
AGP graphics card. Basically I just installed X from the distribution 
CD (along with everything else), it seems to work fine ... BTW I now 
have Gnome installed but not KDE, this is the default for Red Hat 
distributions these days. Can't see that this should be a problem, 
though.

A "top end" graphics card like the Rage128 is likely to use an 
interrupt for the graphics. This may interfere with any interrupt 
used by whatever you have in PCI slot 1 (or sometimes some of the 
higher PCI slots as well). Interference here might well cause 
problems which could manifest themselves as "illegal sumout". Try 
swapping around the PCI cards so that those that can't share 
interrupts don't have to do so. In fact, I find, as a rule of thumb, 
if you have an AGP graphics card installed then don't use PCI slot 1 
or any other PCI slot which shares an interrupt with AGP.

This advice applies wholly irrespective of operating system!


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

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

Date: Thu, 13 Apr 2000 07:31:52 -0400 (EDT)
From: "St. Dee" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: dell poweredge server and Linux SMP.

On Wed, 12 Apr 2000, John R Pierce wrote:

> John R Pierce wrote:
>  >whoops, no they haven't.  If I launch X-windows or something while two
>  >mersenne instances are running, it gets ILLEGAL SUMOUT on both instances
>  >within a few seconds.  Uh oh.  sounds like something wrong with the system
>  >architecture.
> 
> George Woltman answers...
> 
> > not necessarily.  In Windows, ILLEGAL SUMOUTS often occur from
> > drivers or the OS not saving FPU state properly.  Maybe Linux has the
> > same trouble.  If you don't start to get the other error types, I'd
> suspect so.
> 
> 
> Ok, then a question for the group at large...  Anyone else running 2
> instances of mprime on linux on any sort of dual PPro/P-II/P-III/Xeon
> system?  Using something along the lines of 2.2.13ish (This is a Redhat 6.1
> "SBE" edition).  Anyone see Illegal Sumouts when they do things like startx
> then stopx or maybe change display modes?   For what its worth, this
> particular system has a ATI Rage128 onboard and is using XF86_SVGA 3.3.6.

I have two instances of mprime running on a dual Celeron machine under
RH6.0 (with the 2.2.14 kernel) that seems to be working fine.  However, I
do NOT have any GUI installed as there is evidence that the Abit BP6 board
might have trouble with dual processors and GUI interfaces (under both
Linux and WinNT).

I did have a problem with having the rounding error being too big which
turned out to be a memory problem.  Once I put quality memory into the
box, all errors disappeared.  Uptime is around 60 days currently... 

Kel

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

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

Date: Thu, 13 Apr 2000 05:07:49 -0700
From: "John R Pierce" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: dell poweredge server and Linux SMP.

Brian Beesley replies to my query...

> > Ok, then a question for the group at large...  Anyone else running 2
> > instances of mprime on linux on any sort of dual PPro/P-II/P-III/Xeon
> > system?  Using something along the lines of 2.2.13ish (This is a Redhat
> > 6.1 "SBE" edition).
>
> Yep. Two instances of mprime installed in seperate directories.
> System is dual PII-350 in a Supermicro P6DBS board running kernel
> 2.2.12-20smp (straight from the Red Hat 6.1 CD). As a matter of
> principle I run these under a normal user account, not root, and use
> "nice -n20" to control the job priority.

Ok, I have a single copy, using the -A2 flag on the second instance which
tells it to use xxxx0002.xxx for its config files...  that *shouldn't*
matter?  It seems to be auto-nicing itself now.

> >  Anyone see Illegal Sumouts when they do things like
> > startx then stopx or maybe change display modes?   For what its worth,
> > this particular system has a ATI Rage128 onboard and is using XF86_SVGA
> > 3.3.6.
>
> Nope. Starting/stopping/reconfiguring X has no effect except to make
> the mprime processes run more slowly. My system has an ATI Xpert@Work
> AGP graphics card. Basically I just installed X from the distribution
> CD (along with everything else), it seems to work fine ... BTW I now
> have Gnome installed but not KDE, this is the default for Red Hat
> distributions these days. Can't see that this should be a problem,
> though.

This is gnome too.

> A "top end" graphics card like the Rage128 is likely to use an
> interrupt for the graphics. This may interfere with any interrupt
> used by whatever you have in PCI slot 1 (or sometimes some of the
> higher PCI slots as well). Interference here might well cause
> problems which could manifest themselves as "illegal sumout". Try
> swapping around the PCI cards so that those that can't share
> interrupts don't have to do so. In fact, I find, as a rule of thumb,
> if you have an AGP graphics card installed then don't use PCI slot 1
> or any other PCI slot which shares an interrupt with AGP.

Um, this is a server class system.  Has nothing in any of its PCI slots
except a lonely Intel EEPro 10/100 card which isn't even being used.
Everything else is on the motherboard (Adaptec 7880 ultra-narrow scsi,
Adaptec 7899 dual ultra-160-wide scsi, another Intel EEPro 10/100, ATI
Rage128, some kind of ESS sound chip which I don't even have configured).

> This advice applies wholly irrespective of operating system!

true.  Although, I have had my home win98 system configured before where it
had a TON of stuff on  a shared IRQ and never had any problems (for a while,
*everything* seemingly was on IRQ11, this included a 3C905, two different
Symbios SCSI cards, NVidia GeForce256 VGA, USB, and Aureal Vortex II 3D
sound card!).



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

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

Date: Thu, 13 Apr 2000 18:55:40 +0200
From: Martijn Kruithof <[EMAIL PROTECTED]>
Subject: Re: Mersenne: V20 beta #4 (will the beta never end?)

Martijn Kruithof wrote:
Hello, all

Furthermore since the 20.62 % is completed it is only stepping
percentage as fast as the
P-1 phase normally went, the other instance finished the P-2 withing 6
hours!
(This one clearly not)

Could anyone provide me with a beta #3 mprime so that I can rerun the
P-2 stage with a backup?

Kind Regards, Martijn

> 
> Hello all,
> 
> This happened on my machine while switching from beta 3 to beta 4 is
> this correct?
> 
> Starting P-1 factoring on M33237229 with B1=330000, B2=2640000
> Chance of finding a factor is an estimated 4.08%
> P-1 on M33237229 with B1=330000, B2=2640000
> M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292
> clocks)
> 
> And after installing beta 4: (Stage 1 was not redone!)
> 
> Starting P-1 factoring on M33237229 with B1=305000, B2=1525000
> Chance of finding a factor is an estimated 3.58%
> P-1 on M33237229 with B1=305000, B2=1525000
> M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179
> clocks)
> 
> Furthermore a feature would be very nice that it does not recalculate
> the bounds
> without the users consent. (even if it violates the memory bounds)
> 
> The way to run the memory constraints on a dual machine is by the way
> configuring
> day/nighttime differently for the two cpu's as the stage 2 is only very
> short, it does
> not matter if that's only 4 hours (it can resume the next day anyway).
> (i.e.) one has daytime from 6 pm to 6 am, the other from 6 am to 6 pm.
> (real daytime from 19 to 23 pm might yield : daytime from 19 to 6 and
> one daytime from 6 to 23)
> 
> Kind Regards, Martijn
> 
- -- 
http://jkf.penguinpowered.com
Linux distributies voor maar
Fl 10 per CD, inclusief verzendkosten!
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

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

Date: Thu, 13 Apr 2000 13:23:09 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Re: Mersenne: V20 beta #4 (will the beta never end?)

Hi,

At 07:34 AM 4/13/00 +0200, Martijn Kruithof wrote:
>This happened on my machine while switching from beta 3 to beta 4 is
>this correct?
>
>Starting P-1 factoring on M33237229 with B1=330000, B2=2640000
>Chance of finding a factor is an estimated 4.08%
>P-1 on M33237229 with B1=330000, B2=2640000
>M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292
>clocks)
>
>And after installing beta 4: (Stage 1 was not redone!)
>
>Starting P-1 factoring on M33237229 with B1=305000, B2=1525000
>Chance of finding a factor is an estimated 3.58%
>P-1 on M33237229 with B1=305000, B2=1525000
>M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179
>clocks)

The above looks fine!  As was mentioned in whatsnew.txt the program now
does a better job estimating its memory use.  More precisely, beta 3 calculated
the amount of FFT data used, beta 4 adds in the sine/cosine and other data
used during the FFT process.  For your HUGE exponent that's another 4MB or so.

So what happened is beta 4 decided it couldn't allocate as many temporary
variables for FFT data as beta 3 did.  Therefore, stage 2 will be less 
efficient
and thus it is not "worthwhile" to run stage 2 as deep as beta 3 wanted to.

Stage 1 was not redone since you had already done more stage 1 than beta 4's
new stage 1 limit.  Also, since stage 2 bound decreased your percentage 
complete
jumped from 12% to 20%.

One final note.  Whatsnew.txt indicates a relatively rare bug in computing
optimal P-1 bounds was fixed.  You probably ran into this case.  When beta 3
only had enough memory for 4 temporary variables it computed P-1 bounds
assuming it could allocate 5 temporary variables.


>Furthermore a feature would be very nice that it does not recalculate
>the bounds
>without the users consent. (even if it violates the memory bounds)

I'm reluctant to do this.  I don't want prime95 to get a reputation of 
degrading
performance due to thrashing.  Anyway, once you've set your memory parameters
and no longer download a new beta every week, then the computed P-1 bounds
will not change.

>The way to run the memory constraints on a dual machine is by the way
>configuring
>day/nighttime differently for the two cpu's as the stage 2 is only very
>short, it does
>not matter if that's only 4 hours (it can resume the next day anyway).
>(i.e.) one has daytime from 6 pm to 6 am, the other from 6 am to 6 pm.
>(real daytime from 19 to 23 pm might yield : daytime from 19 to 6 and
>one daytime from 6 to 23)

That's one way to do it.  You should be aware however that if prime95 does
not have enough memory to run stage 2 and there is no other work to do, then
it will start the LL test.  This LL work will be wasted if P-1 later finds 
a factor.
Giving stage 2 only 4 hours a day increases the chance that this will happen -
not a major concern, but worth taking into consideration.

Best regards,
George

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

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

Date: Thu, 13 Apr 2000 18:24:12 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: V20 beta #4 (will the beta never end?)

On 13 Apr 00, at 7:34, Martijn Kruithof wrote:

> This happened on my machine while switching from beta 3 to beta 4 is
> this correct?
> 
> Starting P-1 factoring on M33237229 with B1=330000, B2=2640000
> Chance of finding a factor is an estimated 4.08%
> P-1 on M33237229 with B1=330000, B2=2640000
> M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292
> clocks)
> 
> And after installing beta 4: (Stage 1 was not redone!)
> 
> Starting P-1 factoring on M33237229 with B1=305000, B2=1525000
> Chance of finding a factor is an estimated 3.58%
> P-1 on M33237229 with B1=305000, B2=1525000
> M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179
> clocks) 

Looks a bit odd. But if you're _reducing_ the limits it doesn't seem 
to be neccessary to recompute Stage 1, you actually have a bit more 
info than you need to proceed straight to Stage 2.

I wonder if RollingAverage slipped a bit, causing the compute time 
estimate to increase & resulting in lower limits. George, surely this 
is wrong. RollingAverage correction applies identically to the P-1 
factoring time and the LL testing time, so the bounds should not vary 
just because the effective system speed estimate does.

> Furthermore a feature would be very nice that it does not recalculate the
> bounds without the users consent. (even if it violates the memory bounds)

I don't know why the bounds were recalculated in this case. But 
busting the memory bounds is serious. 
> 
> The way to run the memory constraints on a dual machine is by the way
> configuring day/nighttime differently for the two cpu's as the stage 2 is
> only very short, it does not matter if that's only 4 hours (it can resume
> the next day anyway). (i.e.) one has daytime from 6 pm to 6 am, the other
> from 6 am to 6 pm. (real daytime from 19 to 23 pm might yield : daytime
> from 19 to 6 and one daytime from 6 to 23)

Yes, that's one way of doing it. But, if you have them both set to 
the same time window (& given that 2*NightMem is comfortably less 
than the installed memory less whatever is claimed by the OS etc) 
things work OK, P-1 stage 2 just waits until night time comes around.

What worries me about your approach is that, if you have a Stage 2 
running in "night time" on processor 1, then the processor day/night 
switches over and a second Stage 2 starts on processor 2, the Stage 2 
job on processor 1 will continue to completion. If you have set 
2*NightMem bigger than the available system memory, your memory will 
suddenly be overcommitted; the disk activity LED will lock on and the 
system will start to run very slowly indeed.


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

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

Date: Thu, 13 Apr 2000 22:47:10 -0300
From: "Francois LeBlanc" <[EMAIL PROTECTED]>
Subject: Mersenne: GIMPS and other distributed projects

This is a multi-part message in MIME format.

- ------=_NextPart_000_000F_01BFA59A.33DE0C40
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,
I have been lurking on this mailing list for a while now and wish to =
comment on a suggestion that was made a while back.  Someone said that =
maybe a sizeable portion of the GIMPS participants were Seti@Home =
dropouts and regardless of it's questionable chance of success, that =
project is contributing greatly to the development of distributed =
computing on the internet.
    I agree with this.  Personally, I first joined S@H because it was =
the only distributed project I was aware of and I found that very =
concept (distributed computing) very appealing.  Since then, I have =
switched to GIMPS for several reasons.
1- It is easy to use: no need for manual communication like some of the =
more obscure mathematical problems.
2- I found the work worthwhile compared to searching for an impropable =
Alien radio signal or doing brainless code cracking which has no real =
scientific value.
3- Perphaps most important of all, the Seti servers are always having =
problems because there is so much interest in the project (leading me to =
believe that my work is superfluous).  Furthermore, the program used is =
badly unoptimised (the Olli patch made quite a scandal) and  it could be =
optimised very easily (replace the FFT routine). This is further proof =
that my time there was not really needed.
For some reason, I have considered the decision of choosing which other  =
project to join to be an important one (even though I only have a =
Pentium 200).  I might however switch to www.processtree.com (my partner =
# is 5766 for those interested) which plans on paying people for their =
computer's time (very appealing) or Cosm (cosm.mthral.org) which are =
going to do lots of things and seem to me very organised. It's creator =
helped launch ditributed.net.

    On another note, I want to convince my University faculty (Science) =
to run Prime 95 in the computer labs.  How can I prove that the client =
will not affect the performance of the computers; even the old Pentium =
60ish. I'm not sure if I believe that myself.  And at what speed do =
computers start being automatically assigned factoring assignments.  Do =
you have suggestions on how to accomplish this? I've already spoken to a =
technician but he wasn't very collaborative, saying that all sorts of =
permissions were needed but I haven't given up yet.

Francois LeBlanc

- ------=_NextPart_000_000F_01BFA59A.33DE0C40
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have been lurking on this mailing =
list for a=20
while now and wish to comment on a suggestion that was made a while =
back.&nbsp;=20
Someone said that maybe a sizeable portion of the GIMPS participants =
were=20
Seti@Home dropouts and regardless of it's questionable chance of=20
success,&nbsp;that project is contributing greatly to the development of =

distributed computing on the internet.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I agree with =
this.&nbsp;=20
Personally, I first joined S@H because it was the only distributed =
project I was=20
aware of and I found that very concept (distributed computing) very=20
appealing.&nbsp; Since then, I have switched to GIMPS for several=20
reasons.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1-&nbsp;It is easy to use: no need for =
manual=20
communication like some of the more obscure mathematical =
problems.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2-&nbsp;I found the work worthwhile =
compared to=20
searching for an impropable Alien&nbsp;radio signal or doing brainless =
code=20
cracking which has no real scientific value.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3- Perphaps most important of all, the =
Seti servers=20
are always having problems because there is so much interest in the =
project=20
(leading me to believe that my work is superfluous).&nbsp; Furthermore, =
the=20
program used is badly unoptimised (the Olli patch made quite a scandal)=20
and&nbsp; it could be optimised very easily (replace the FFT =
routine).&nbsp;This=20
is further proof that my time there was not really needed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>For some reason, I have considered the =
decision of=20
choosing&nbsp;which other  project to join to be an important one (even =
though I=20
only have a Pentium 200).&nbsp; I might however switch to <A=20
href=3D"http://www.processtree.com">www.processtree.com</A>&nbsp;(my=20
partner&nbsp;# is 5766 for those interested) which plans on paying =
people for=20
their computer's time (very appealing) or Cosm (<A=20
href=3D"mailto:[EMAIL PROTECTED]">cosm.mthral.org</A>) =
which are=20
going to do lots of things and seem to me very organised. It's creator =
helped=20
launch ditributed.net.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; On another note, I =
want to=20
convince my University faculty (Science) to run Prime 95 in the computer =

labs.&nbsp; How can I prove that the client will not affect the =
performance of=20
the computers; even the old Pentium 60ish.&nbsp;I'm not sure if I =
believe that=20
myself.&nbsp; And at what speed do computers start being automatically =
assigned=20
factoring assignments.&nbsp; Do you have suggestions on how to =
accomplish=20
this?&nbsp;I've already spoken to a technician but he wasn't very =
collaborative,=20
saying that all sorts of permissions were needed but I haven't given up=20
yet.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Francois =
LeBlanc</FONT></DIV></BODY></HTML>

- ------=_NextPart_000_000F_01BFA59A.33DE0C40--

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

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

Date: Thu, 13 Apr 2000 20:02:13 -0700
From: "John R Pierce" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: dell poweredge server and Linux SMP.

> I have a dual PII/333 system, but I run recent kernels.  I can try to put
an
> old one on it and fire up X if you would like.  Video on that machine is a
> Riva TNT2 Ultra.

the kernel is 2.2.13-5.0 which is just one shy of the latest production
2.2.14 kernel.  I can't imagine there's any SMP specific issues here, but I
dunno.  Or by 'recent' do you mean 2.3.xx experimentals?

X wasn't the issue.  After doing a few odds and ends on the machine that
caused memory to get swapped around, it started cacking out all on its own
with the two instances running concurrently and nothing else.

I went ahead and 'quit gimps' on that box.  I can't afford to dedicate any
more time to getting #$@#$ ILLEGAL SUMOUTS.  Gotta get back to hacking on
the oracle database whats this machine's true purpose in life.

- -jrp


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

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

Date: Fri, 14 Apr 2000 07:56:33 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: GIMPS and other distributed projects

On 13 Apr 00, at 22:47, Francois LeBlanc wrote:

>     On another note, I want to convince my University faculty (Science) to
>     run Prime 95 in the computer labs.  How can I prove that the client
>     will not affect the performance of the computers; even the old Pentium
>     60ish. I'm not sure if I believe that myself.

On Windows machines, if you have the priority set to 1, then the 
operating system will always run anything which is running at a 
higher priority than 1 and actually needs CPU time, rather than 
running Prime95. Normal applications run at 7, even screensavers run 
at 4. In other words, the OS will only give CPU cycles to Prime95 if 
there is nothing else in a position to use them.

There is a _small_ memory overhead - the memory used by Prime95 for 
its work vectors can be significant on systems with very limited 
memory. The good news here is that the memory overheads are 
proportional to the exponent, so running double checks on current 
assignments (around 5 million) needs only 4 or 5 megabytes. Better 
still, trial factoring assignments use very little memory, well under 
1 megabyte.

The network overheads are a few hundred bytes occasionally. Certainly 
nothing to be concerned about.

Don't forget you can also use the "time of day" stuff (in prime.ini) 
to make Prime95 get completely off the system at times when the 
system is required to be 100% dedicated to user applications.

Basically what I'm saying is that, if you can run what the users want 
on a system (no matter how slow it is or how ungenerous its memory), 
running Prime95 in the background as well should make no perceivable 
difference to the system so far as users are concerned. For instance, 
I have Prime95 running double-checks on a P100 laptop with 24 MB 
memory; this system is noticeably under-resourced for running e.g. 
Netscape Communicator 4.7, but shutting down Prime95 doesn't make it 
obviously less so.

There is one exception known to me. If the user is running a program 
under the control of a software based debugger, then running Prime95 
(or _any_ other background CPU soak program) can cause significant 
performance degradation, not because of the resources used by Prime95 
but because of all the extra task switches generated at each debugger 
trap point - this can be as often as after every machine instruction 
executed by the program being debugged.

>  And at what speed do
>     computers start being automatically assigned factoring assignments. 

Used to be 50 MHz (based on CPU speed set in CPU/Options, multiplied 
by 0.001 * RollingAverage (from local.ini), multiplied by hours per 
day set in CPU/Options, divided by 24). But you can override the 
automatic assignment type using the Test/PrimeNet menu.

>     I've already spoken
>     to a technician but he wasn't very collaborative, saying that all
>     sorts of permissions were needed but I haven't given up yet.

Yes, you _do_ need permission, at the level of corporate beaurocracy. 
But the network priveleges required are minimal, essentially 
Prime95's communications with PrimeNet will work if the system can 
see PrimeNet's home page with an ordinary web browser. Unlike some 
projects, Prime95 does _not_ automatically change its program code 
under control of the server, so running Prime95 does not present any 
particular problems from the point of view of system security.

Unfortunately, tiny minds with power will always come up with 
"technical" objections when what they really mean is "I can't be 
bothered" 8-(


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

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

Date: Sat, 15 Apr 2000 04:22:23 +0200 (CEST)
From: Henrik Olsen <[EMAIL PROTECTED]>
Subject: Re: Mersenne: V20 beta #3

Hi,

I just tried downloading 20.3, both mprime and sprime, as well as tried
with mprime 19.0.2 .
None of them where able to detect the network as being available on a
machine running Mandrake Linux, kernel version 2.2.14-15mdksecure,
probably due to /proc/net not being readable by non-root on such a system,
which is a bit of a bummer, as I as I don't want to have to run it as
root. :(

Does a solution exist for running mprime on such a system or will I have
to use this one as well for SNFS sieving instead of GIMPS?

- -- 
Henrik Olsen,  Dawn Solutions I/S       URL=http://www.iaeste.dk/~henrik/
Many are my names in many countries. [EMAIL PROTECTED] among
the Elves, [EMAIL PROTECTED] to the Dwarves; [EMAIL PROTECTED] I was
in my youth in the West that is forgotten, in the South [EMAIL PROTECTED], 
in the north [EMAIL PROTECTED]; to the East I go not.
                                                   With thanks to Tolkien



_________________________________________________________________
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 #718
******************************

Reply via email to