Mersenne Digest Sunday, March 5 2000 Volume 01 : Number 702 ---------------------------------------------------------------------- Date: Sat, 4 Mar 2000 00:11:42 +0000 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: Security and Prime95/mprime On Fri, Mar 03, 2000 at 04:46:30AM -0800, Paul Leyland wrote: >George is an honorable man, I'm sure, and has not knowingly put in any >loopholes. I'm equally sure that he's not infallible and that he will >freely admit to this. Do *you* want to bet the security of your site even >more than you are now doing? Suggestion: Compile mprime from source code. Then you have it all there. Sure, you won't get credit (since the security codes are zeroed out), but you will still contribute to the project. /* Steinar */ - -- Homepage: http://members.xoom.com/sneeze/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 03 Mar 2000 19:27:47 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: searching the biggies >From: George Woltman <[EMAIL PROTECTED]> >To: "Nathan Russell" <[EMAIL PROTECTED]> >Subject: Re: Mersenne: searching the biggies >Date: Fri, 03 Mar 2000 16:32:10 -0500 > >Hi, > >>I don't honestly think I would have the patience to run 10 M tests, > >Me too. 1 year for a 1 in 250,000 chance - no thanks. I've had a computer >do ECM factoring for a year just for some variety. > >Regards, >George > I sympathize. I just set my 'work to cache' value up by two weeks and got a batch of factoring assignments, just for variety. I shut my program down and re-organized the worktodo file so those were interspersed with the tests, for variety's sake. I checked all the carriage returns and stuff before I saved it and started the client; was there any risk in doing that? I have Gateway Goback (A program that constantly saves about 500 meg of the most recent versions of changed files) so I can undo it if need be. Nathan ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 03 Mar 2000 19:41:12 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: searching the biggies >From: Jukka Tapani Santala <[EMAIL PROTECTED]> >To: Nathan Russell <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: Mersenne: searching the biggies >Date: Sat, 4 Mar 2000 01:19:56 +0200 (EET) > >On Fri, 3 Mar 2000, Nathan Russell wrote: > > >>Two of their other projects lost GIMPS-years of work each because of > > >>stupid bugs and I got fed up and left. > > >Uh... we had a bug too. Ironically, it was announced on April Fools >Day > > >last year. That caused quite a stir. We lost roughly a GIMPS month of > > >work. > > I am aware that there was a bug in V 17. There will always be bugs. >The > > bugs (plural) that occured in my former project were merely the final >reason > > that I decided to leave. > >Incidentally, what bothers me about the "other project" is not that they >had bugs, but more that the explanations of the bugs don't seem to check >up(*), to such a degree as they bother to even state what the issues >were. In fact they had a third, similiar incident involving the suspected >delay in announcing the finishing of one competition long back, altough I >don't remember/know enough details to comment other than that to note they >do certainly seem to have a history of this sort of stuff cropping >up. Incidentally, could you imagine them having a "Make noise if correct >solution found?" option in their clients... ;) Not in, um, about as long as it would take to test MM(127)! > >(*) For the most recent problem... As far as I can tell, when switching >between systems - even between OS'es on the same computer - the involved >client versions would happily restart the current work unit losing all >work so far. The announcement about the bug claimed it would only occur in >such a situation, which thus should not happen. > >To further confuse issues, the announcement claims that they have to >abandon all work so far because the faulty packets are undetectable, and >that the problem generating the faulty packets has been fixed, but in >practically same breath continues that servers have been made to reject >the faulty packets... Which should be both non-existent and impossible to >spot? That is quite an interesting question. > >And exactly how does incorrect count of possible solutions in a >pre-defined block invalidate the results, anyway? I think OGR could be one >of the most useful applications distributed computing has been applied to >so far, but unfortunately I can't feel comfortable my CPU-ticks go towards >what I want and I am getting full disclosure with who are running it now. It seems to me that they must have had an issue with some aspect of the client that they are unwilling to publically discuss. Perhaps the issue that occured couldn't be described without giving away vital info about their verification code. Even if that were the case, however, one would think that they would merely say so, or even a simple "We found a bug, wait for a new version to come out" rather than lying to everyone. > > >Incidentally, have you seen JETI@home? Unfortunately I don't remewmber the >URL right now, but that's worth checking out, too, at least if you don't >take everything related to distributed computing too seriously ;) I thought it was YETI@home > >Incidentally#2, has anybody looked into the application of distributed >computing into genetics? With the increased availability of genetic >information online, on the WWW, such applications don't seem too >far-fetched. Sounds like a neat field... > >Anyway, sorry to sound out, but I am feeling rather incensed by the way I >perceive many distributed computing operations to disrespect/waste their >contributors and the resources. Words seem to fail me in correctly >describing it just now, but I hope you can see what I mean. I think the >least Distributed Computing outfits "owe" to their contributors is a clean >accounting of what their CPU-time has went towards. I happen to know that SETI duplicates their work two or three times, for example Nathan > > -Donwulff > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 03 Mar 2000 18:42:48 -0800 From: Spike Jones <[EMAIL PROTECTED]> Subject: Re: Mersenne: searching the biggies 2 Nathan Russell wrote: > Last time I checked, there were two universtites (labeled as such that is) > at the top of the list but no companies really near the top. Ja, however if someone manages to get a reallllly big company to play, there might be some very good reasons to *not* show up in the top contributors list. In fact, the someone who organized and pushed thru the effort might even want to conceal her own efforts in that direction. spike _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 04 Mar 2000 11:27:46 -0600 From: Ken Kriesel <[EMAIL PROTECTED]> Subject: Mersenne: QA testing At 05:42 PM 3/3/2000 +0800, "Dave Mullen" <[EMAIL PROTECTED]> wrote: >For interest, has anyone calculated benchmarks, or run LL tests in those ranges; >I guess not many, 8 months is a long time to wait for a result !! A select group of volunteers have been running factoring and LLtests as part of the QA effort, with the long range goal of producing multiple tested and double checked exponents in every fft length that prime95 currently supports. We've had occasional setbacks, including the necessity to repeat in v19.2, trial factoring for exponents above 2^32/120=~35.79 million after the discovery of a carry error in the factoring code present in v19.0 and v19.1. Some volunteers have dropped out, due to various reasons including lack of time & job changes. The folks who are signing out 10M-digit candidate exponents from the primenet server are also contributing to the QA effort, intentionally or not. Due to the dropout of some of the volunteers, we have some open exponents, so I'm now looking for some more volunteers. Here's a repost, with minor edits, of the call for volunteers from September 1999: I am looking for about 10 additional ambitious & very patient QA testers with extremely fast hardware, and some significant free storage space, to participate in runs on selected exponents in the larger fft runlengths. The selected exponents will frequently be fully trial factored, or nearly so. Though many may be prime95 or mprime users, this is not a requirement, and participation of users on nonIntel cpus is encouraged. 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. Interim files (which can each be sizable) should be preserved until interim residues of a later interim check are known to match. (Ideally all interim files would be kept, at intervals of 1-2 million iterations, until an exponent is completed & double checks ok.) Participants should agree to sign on for at least 6 months, preferably much longer, and to transmit the last valid intermediate file or interim file to an ftp server if quitting, or when necessary for debugging. (Note, the upper end, 79,300,000, takes an estimated 6.5 years on a PentiumII-400, 24x7x365, nonstop on an idle system. A good backup strategy is highly recommended for the higher exponents.) Participants should agree to install version upgrades that may be required from time to time, waiting a day or more to ensure it's a stable version, and migrate the tests in progress to their fastest available hardware as hardware upgrades are made. (It may be possible to get partial cpu-time credit for partially LLtesting an exponent that is then completed by someone else but this is not guaranteed. This could be an extra administrative headache for George Woltman and myself.) In exchange for all this time and trouble, testers will have a reduced chance of finding a prime and a delay in receiving cpu credit (due to the long runtimes), but get a shot at completing primality tests of exponents unlikely to be surpassed for some time, and the satisfaction of making a contribution to the reliability of and confidence in the program. The purposes of this endeavor are: 1) Add to the list of known, checked residues, some entries in currently very sparse or completely empty runlengths (ahead of checkout & result return by typical GIMPS & Primenet users) for qualification of v19 prime95 & its variants, future versions, & other software. 2) Verify the long term operation accuracy of prime95 v19 and its relatives (and later versions) in the new longer runlengths. 3) Gain experience with the tandem-running approach. 4) Have fun. Volunteers, please respond by email to me with the following information: Your full name your email address your preferred runlength(s) how many exponents you'd like to take on in each runlength Description of cpus available for QA testing, as in the hypothetical example below, to judge suitability of cpus for various exponents: Name CPU OS RAM available (hr/day)/(day/wk) xyz PII-500 WinNT (build 1381 SP5) 128MB 24/7 a Alpha21264-600 TruUnix Vxxx 512MB 15/5 +24/2 5; various Celeron500 Win95 128MB 24/7 omega 4xPIII-600 WinNT 4sp5+hotfixes 256MB 24/7 (CPU descriptions will not be shared among participants or with the mail list.) Ken (Tester of the currently 2nd, 3rd, 4th, & 5th highest single-LL-tested exponents; Cotester of the highest doublechecked exponent:M15,500,057.) _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 04 Mar 2000 14:58:51 -0500 From: Matthew Smith <[EMAIL PROTECTED]> Subject: Mersenne: 386SX I just installed Slackware 7.0 on an old 386SX and I want it to do distributed computing of some kind. However, the lowest CPU mprime allows is a 486. What can I do? _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 4 Mar 2000 12:27:52 -0800 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX > I just installed Slackware 7.0 on an old 386SX and I want it > to do distributed computing of some kind. However, the > lowest CPU mprime allows is a 486. What can I do? phew. a 386sx is SO slow I really can't imagine WHAT useful computational work it could do... Thats a 25 or so MHz CPU with a 16 bit bus that probably takes 5-6 clocks to do a simple integer operation. Oh, and its got no floating point. I'd estimate it at least a few 100 times slower than even a slow celeron at numerical work. No, wait. make that several THOUSAND times slower. - -jrp _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 4 Mar 2000 19:01:51 -0500 From: Walt Mankowski <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX On Sat, Mar 04, 2000 at 12:27:52PM -0800, John R Pierce wrote: > > I just installed Slackware 7.0 on an old 386SX and I want it > > to do distributed computing of some kind. However, the > > lowest CPU mprime allows is a 486. What can I do? > > phew. a 386sx is SO slow I really can't imagine WHAT useful computational > work it could do... Thats a 25 or so MHz CPU with a 16 bit bus that > probably takes 5-6 clocks to do a simple integer operation. Oh, and its got > no floating point. I'd estimate it at least a few 100 times slower than > even a slow celeron at numerical work. No, wait. make that several > THOUSAND times slower. It might be able to work on one of the distributed.net projects. I don't *think* the rc5 stuff uses floating point. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 4 Mar 2000 16:30:34 -0800 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX > > phew. a 386sx is SO slow I really can't imagine WHAT useful computational > > work it could do... Thats a 25 or so MHz CPU with a 16 bit bus that > > probably takes 5-6 clocks to do a simple integer operation. Oh, and its got > > no floating point. I'd estimate it at least a few 100 times slower than > > even a slow celeron at numerical work. No, wait. make that several > > THOUSAND times slower. > > It might be able to work on one of the distributed.net projects. I > don't *think* the rc5 stuff uses floating point. it doesn't. However, even at 32 bit integer programming, figure the 16 bit 386SX will be around 4-8 times slower than a 486 at the same clock speed, which in turn is 3-4 times slower than a pentium at the same clock speed. now throw in the differential between the 16-25MHz range of the typical 386SX to the 400-600Mhz of a modern celeron or pentium or k6 today and we can figure ANOTHER 20X slower. 386SX systems didn't use any level 2 cache either, and only had like 8k of level 1 cache, and the 386SX memory bus took 2-3 clocks minimum to transfer 16 bits with no burst cycle support. All told, that 386SX will be something like 100 times slower than a bottom of the barrel Celeron or K6 system and probably draw at least as much power. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 04 Mar 2000 19:41:09 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX >From: Walt Mankowski <[EMAIL PROTECTED]> >To: Mersenne discussion list <[EMAIL PROTECTED]> >Subject: Re: Mersenne: 386SX >Date: Sat, 4 Mar 2000 19:01:51 -0500 > (much snippage) >It might be able to work on one of the distributed.net projects. I >don't *think* the rc5 stuff uses floating point. It does not, and neither does OGR. Nathan ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 4 Mar 2000 19:52:51 -0500 From: Walt Mankowski <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX On Sat, Mar 04, 2000 at 04:30:34PM -0800, John R Pierce wrote: > > > phew. a 386sx is SO slow I really can't imagine WHAT useful > computational > > > work it could do... Thats a 25 or so MHz CPU with a 16 bit bus that > > > probably takes 5-6 clocks to do a simple integer operation. Oh, and its > got > > > no floating point. I'd estimate it at least a few 100 times slower > than > > > even a slow celeron at numerical work. No, wait. make that several > > > THOUSAND times slower. > > > > It might be able to work on one of the distributed.net projects. I > > don't *think* the rc5 stuff uses floating point. > > it doesn't. As far as I can tell from the information available at www.distributed.net, it does. There is quite a bit of client speed data at http://n0cgi.distributed.net/speed/, including a variety of different 386SX processors. > However, even at 32 bit integer programming, figure the 16 bit 386SX will be > around 4-8 times slower than a 486 at the same clock speed, which in turn is > 3-4 times slower than a pentium at the same clock speed. now throw in the > differential between the 16-25MHz range of the typical 386SX to the > 400-600Mhz of a modern celeron or pentium or k6 today and we can figure > ANOTHER 20X slower. 386SX systems didn't use any level 2 cache either, and > only had like 8k of level 1 cache, and the 386SX memory bus took 2-3 clocks > minimum to transfer 16 bits with no burst cycle support. > > All told, that 386SX will be something like 100 times slower than a bottom > of the barrel Celeron or K6 system and probably draw at least as much power. According to the dnet client speed page, a 386SX-33 can do about 16,000 RC5 keys/sec. My P3-450 can do about 1,264,000 kps. That's less than 80 times faster. Walt _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 04 Mar 2000 19:52:15 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX >From: "John R Pierce" <[EMAIL PROTECTED]> >To: "Walt Mankowski" <[EMAIL PROTECTED]>, "Mersenne discussion >list" <[EMAIL PROTECTED]> >Subject: Re: Mersenne: 386SX >Date: Sat, 4 Mar 2000 16:30:34 -0800 > > > > phew. a 386sx is SO slow I really can't imagine WHAT useful >computational > > > work it could do... Thats a 25 or so MHz CPU with a 16 bit bus that > > > probably takes 5-6 clocks to do a simple integer operation. Oh, and >its >got > > > no floating point. I'd estimate it at least a few 100 times slower >than > > > even a slow celeron at numerical work. No, wait. make that several > > > THOUSAND times slower. > > > > It might be able to work on one of the distributed.net projects. I > > don't *think* the rc5 stuff uses floating point. > >it doesn't. > >However, even at 32 bit integer programming, figure the 16 bit 386SX will >be >around 4-8 times slower than a 486 at the same clock speed, which in turn >is >3-4 times slower than a pentium at the same clock speed. now throw in the >differential between the 16-25MHz range of the typical 386SX to the >400-600Mhz of a modern celeron or pentium or k6 today and we can figure >ANOTHER 20X slower. 386SX systems didn't use any level 2 cache either, >and >only had like 8k of level 1 cache, and the 386SX memory bus took 2-3 clocks >minimum to transfer 16 bits with no burst cycle support. > >All told, that 386SX will be something like 100 times slower than a bottom >of the barrel Celeron or K6 system and probably draw at least as much >power. It ought to be cheaply upgradable to a low pentium, which could be useful also as a computer for, for example, text editing while the main one is otherwise occupied. Nathan ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 4 Mar 2000 19:59:00 -0500 From: Walt Mankowski <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX On Sat, Mar 04, 2000 at 07:41:09PM -0500, Nathan Russell wrote: > > > > >From: Walt Mankowski <[EMAIL PROTECTED]> > >To: Mersenne discussion list <[EMAIL PROTECTED]> > >Subject: Re: Mersenne: 386SX > >Date: Sat, 4 Mar 2000 19:01:51 -0500 > > > > (much snippage) > > >It might be able to work on one of the distributed.net projects. I > >don't *think* the rc5 stuff uses floating point. > > It does not, and neither does OGR. I just asked some folks on #distributed. They say it will run, but that the box needs to be in DOS mode. At any rate, it's easy enough to find out. Just download the client and see if it works. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 04 Mar 2000 23:00:09 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX >From: Walt Mankowski <[EMAIL PROTECTED]> >To: Mersenne discussion list <[EMAIL PROTECTED]> >Subject: Re: Mersenne: 386SX >Date: Sat, 4 Mar 2000 19:52:51 -0500 > >On Sat, Mar 04, 2000 at 04:30:34PM -0800, John R Pierce wrote: > > > > phew. a 386sx is SO slow I really can't imagine WHAT useful > > computational > > > > work it could do... Thats a 25 or so MHz CPU with a 16 bit bus that > > > > probably takes 5-6 clocks to do a simple integer operation. Oh, and >its > > got > > > > no floating point. I'd estimate it at least a few 100 times slower > > than > > > > even a slow celeron at numerical work. No, wait. make that several > > > > THOUSAND times slower. > > > > > > It might be able to work on one of the distributed.net projects. I > > > don't *think* the rc5 stuff uses floating point. > > > > it doesn't. > >As far as I can tell from the information available at >www.distributed.net, it does. There is quite a bit of client speed >data at http://n0cgi.distributed.net/speed/, including a variety of >different 386SX processors. I will check that information. > > > However, even at 32 bit integer programming, figure the 16 bit 386SX >will be > > around 4-8 times slower than a 486 at the same clock speed, which in >turn is > > 3-4 times slower than a pentium at the same clock speed. now throw in >the > > differential between the 16-25MHz range of the typical 386SX to the > > 400-600Mhz of a modern celeron or pentium or k6 today and we can figure > > ANOTHER 20X slower. 386SX systems didn't use any level 2 cache either, >and > > only had like 8k of level 1 cache, and the 386SX memory bus took 2-3 >clocks > > minimum to transfer 16 bits with no burst cycle support. > > > > All told, that 386SX will be something like 100 times slower than a >bottom > > of the barrel Celeron or K6 system and probably draw at least as much >power. > >According to the dnet client speed page, a 386SX-33 can do about >16,000 RC5 keys/sec. My P3-450 can do about 1,264,000 kps. That's >less than 80 times faster. > >Walt 16 K keys/sec would take about 4 1/3 hours to do one block of keys. That is an output that would allow one to see the machine's placement in stats on a daily basis running packets of 1, 2 or 4 blocks. I am tempted to say that D.Net would be the best choice. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com _________________________________________________________________ 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 07:39:46 -0500 From: "Ethan O'Connor" <[EMAIL PROTECTED]> Subject: Mersenne: Mersenne Timings 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 A few items of interest: The fastest timing per Mhz, relative to a PPro/200, is the Athlon/500 which is 1.5 times faster. The slowest is (not surprisingly) the sole 486 on the list, which is only 13% as fast per Mhz as the PPro :) I even dug out a 386SX/25; many years ago, I actually tried to test 2^60103-1 on the same machine (using the very first web-released version of the GIMPS software!) before realizing it was too slow even for that exponent. I guess there are some instructions in the current executable which the floating point emulation can't handle, however, so no timings from it :) Ethan O'Connor [EMAIL PROTECTED] _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 05 Mar 2000 12:43:52 -0500 From: Matthew Temus Smith <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX Joth Tupper wrote: > The 386SX has no numeric co-processor (on-board CPU for 486 and up). > If you installed a 387 co-processor, you might have some hope -- others know > a ton more than I do. > > Without hardware level float point operations, I would exclude LL tests from > my experiments. In all honesty, it cannot hurt (much) to install a version > of the GIMPS > software and try it out on small exponents. > > The problem is that a 20 Mhz 386 is loosely comparable to a 3 Mhz P-II. > > ----- Original Message ----- > From: "Matthew Smith" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 04, 2000 11:58 AM > Subject: Mersenne: 386SX > > > I just installed Slackware 7.0 on an old 386SX and I want it > > to do distributed computing of some kind. However, the > > lowest CPU mprime allows is a 486. What can I do? > > > > _________________________________________________________________ > > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > > It does have that co-processor, but mprime gave me an error message when I tried to select 486 (closest thing) @ 25 MHz. Another problem I have is the fact that it's not hooked up to the Internet. It has a network card and a modem, but I don't want to pay the University for another connection. I should do manual tests, which are ok for GIMPS, but I can't figure out how it's accomplished with distributed.net projects. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 05 Mar 2000 17:30:07 -0500 From: Matthew Temus Smith <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX Thanks for the info. I'll look into setting this up once I get another network card for the 386. Matthew Smith _________________________________________________________________ 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 19:29:05 -0500 (EST) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Subject: Re: Mersenne: 386SX > > The problem is that a 20 Mhz 386 is loosely comparable to a 3 Mhz > P-II. It's much much worse than that. Even with a coprocessor, a floating point add or multiply on a 386 takes 28-57 clocks; on the PII it takes one, if scheduled carefully. When the 386 and 486 were state of the art, some people used to make a distinction between a PC and "a real computer". It wasn't because those people were snobs. jasonp _________________________________________________________________ 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 #702 ******************************
