Mersenne Digest Saturday, August 7 1999 Volume 01 : Number 611 ---------------------------------------------------------------------- Date: Thu, 5 Aug 1999 17:34:49 -0400 From: Pierre Abbat <[EMAIL PROTECTED]> Subject: Re: Mersenne: Closing a 9x Program On Thu, 05 Aug 1999, Arnold R. Hart wrote: > I have a laptop and can't seem to figure out how to run prime95 when the > laptop is plugged in, but not when it is operating on battery power. I'm > running MS Win'98. (release 2???) The powermanagement software will let > me start prime95 (18.1) when I boot, but if I log-off, then prime95 exits. > If I install prime95 as a service, then I can't seem to shut it down via > the power save since I didn't start it via the power save software. > As I see it, the easiest solution would be to find a way to close it from > the command line. My power save software allows me to set "warnings" that > will run given programs when the batery gets below a certain level. I'd > like to, unless there is a better solution, set a warning at 99% that would > run a batch file to close prime95. Is this possible? I don't know if it's possible to suspend a program from the command line in Windows, but if there's a way to do it, you can probably do it with kill in Cygwin. (I don't know offhand if Cygwin has kill.) I have a cron job on the laptop that automatically starts nfsieve (I'm running mprime on the desktop) if it isn't running and nfs.out exists, renices it, and suspends it if the battery is low or restarts it if it is high. phma _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 5 Aug 1999 18:21:31 -0400 From: Bryan Fullerton <[EMAIL PROTECTED]> Subject: Re: Mersenne: odd thought... On Thu, Aug 05, 1999 at 03:31:55PM -0600, "Blosser, Jeremy" <[EMAIL PROTECTED]> wrote: > I know that OpenGL supports double precision matrix transforms, and with > todays super duper 3D accelerator cards, wouldn't it be possible to do an > FFT via OpenGL and take advantage of the 3d hardware? Or am I completely off > my rocker. (as usual) :) As the owner of an NVidia TNT2 Ultra video card, I'd be interested in this as well. ;) Bryan - -- Bryan Fullerton http://www.samurai.com/ Core Competency Samurai Consulting "No, we don't do seppuku." Can you feel the Ohmu call? _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 5 Aug 1999 23:44:01 +0100 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Multiple residues - enhancing double-checking On 5 Aug 99, at 9:05, Eric Hahn wrote: > Based on previous messages in this thread, I'm going > to throw in my 2 cents... (and avoid a lot of > quoting!) And I'm doing the same. I'd probably have reacted sooner if I hadn't been offline (getting a kidney stone fixed). Several months ago I suggested a method which does require some work on both client and server, but which really does reduce wasted work to a minimum. The way it works is as follows: Assign each exponent initially to two systems A and B. The software has a table of checkpoints built in (these can be very sparse for smaller exponents, becoming denser as the exponent increases, so as to maintain about 1 P90 month between checkpoints). Suppose A reaches the first checkpoint before B. A stops working on the exponent & moves on to some other work already queued. It reports the iteration number and the low 64 bits of the residue to the PrimeNet server. When B reaches the first checkpoint, it also stops working on the exponent & gets on with something else. It also reports the iteration number & the low 64 bits of the residue to the PrimeNet server. The PrimeNet server then checks to see if the checkpoint information matches that sent in by another system. If it does, it immediately sends a message to B instructing B that it can continue with the checked exponent up to the next checkpoint. It also tags a message to be sent to A instructing A to proceed with the checked exponent, which is communicated to A next time A checks into the server. If B's checkpoint info doesn't match A's, the exponent is issued to another system C which calculates to the first checkpoint & check in, as before. If we now have two matching residuals, the two systems supplying them are told to continue and the system with the "wrong" result is told to abandon that exponent. If all three differ, issue the exponent to system D ... The last iteration (completing the run) is treated in the same way as an intermediate checkpoint, except that there is no need for the PrimeNet server to send a "continue" or "abort" command - though this might provide useful feedback to the user, if it was done anyway. As well as minimising wasted work, this scheme results in very little extra server traffic, since the systems all need to check in occasionally anyway. If Prime95 is altered so that it always works on the _smallest_ exponent it has "in hand", work should be completed reasonably quickly and in reasonable order. (Especially bearing in mind that this scheme completes double-checking at the same time as first tests!) When a prime is found, the discovery credit (& any prize money) should obviously be split between the two users who ran the last iteration on the exponent in question. > I think as the time increases for each LL test, there > would be much more time savings in attempting to do > higher trial-factoring. Yes, trial factoring to a higher limit does help, but, unfortunately, as well as each extra bit of factoring depth costing much time as all the previous work, the chance of finding a factor (in a "window" of any particular fixed size) decreases steadily as the factoring depth increases. There is also going to be a jump in factoring time somewhere around 62/63/64 bits due to hardware limitations of the Intel architecture. Don't forget, factoring time is O(2^d/p) whereas LL testing time is "only" O(p^2 * log p), where p is the exponent and d is the factoring depth in bits. Finally, although save files for exponents > 33 million are going to be a considerable size (14 MBytes for exponents just big enough to have 10 million decimal digits), it might be worth considering an _option_ where users (with fast network connections) could deposit save files for "safe keeping" (as a backup). As has been pointed out elsewhere, this would save time in the event that a user goes AWOL. Clearly it isn't reasonable to expect users with dial-in connectivity to transmit files > 10MBytes long with any frequency, but, for users with high-speed connections, it doesn't represent much of a problem. The other issue is finding enough disk space to store a large number of these files ... they don't compress very well, either! 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, 5 Aug 1999 17:03:34 -0700 From: "Joth Tupper" <[EMAIL PROTECTED]> Subject: Fw: Mersenne: Multiple residues - enhancing double-checking, test factoring Some days I should just keep it to myself. As some of you may have noticed, few odd primes are the sum of two other primes. (Not a good day for me, I think.) There may be some meat on this bone, tho'. >>Another thought: does the factor test already use Goldbach's conjecture? > Someone with more cleverness and time than I have right now might think > about using this fact: > > Given p,q integers and r = p+q. Then Mr = Mp.Mq + Mp + Mq How about p,q primes with r = p + 2q. This might work since Mq | M(2q) = Mq(Mq + 2). So, Mr = Mp.M(2q) + Mp + M(2q) The other notion of using a database of factors might still be interesting although the link to Goldbach's conjecture seems to vanish. > This is just: Mp.Mq = (2^p - 1)(2^q - 1) = 2^(p+q) - 2^p - 2^q + 1 = Mr - > Mp - Mq Suppose we want to factor test Mr. Perhaps we can (by trial and error) find primes p and q with r = p+2q. Mr, Mp and Mq are relatively prime in pairs, so none of the factors of Mp or Mq divide Mr. Now, if F is a test factor in the range, suppose we keep a database of Fp = Mp mod F. This is big, but once we have r=p+2q, we just calculate Fp.Fq.(Fq+2) + Fp +Fq(Fq+2) mod F. If 0, then F divides Mr. > One practical question is how bloody big is this collection of Fp's? > > Could this make test factoring run faster? > Joth _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 02:47:27 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: RE: Mersenne: Multiple residues - enhancing double-checking > If B's checkpoint info doesn't match A's, the exponent is issued to > another system C which calculates to the first checkpoint & check in, > as before. If we now have two matching residuals, the two systems > supplying them are told to continue and the system with the "wrong" > result is told to abandon that exponent. If all three differ, issue > the exponent to system D ... The main way to speed this up is to have system C continue from the last residue that it is known that system A and B agree upon. Or, possibly even better (though more error prone) would be to have A and B recalculate from last agreed upon residue, and see if they now agree. This would waste at most 2 P90 months, without having to transfer it over the network, or have system D doing half the agreed upon work. I think it's safe to say that if system A and B can agree on the residue at that point, then it is the correct residue. > As well as minimising wasted work, this scheme results in very little > extra server traffic, since the systems all need to check in > occasionally anyway. If Prime95 is altered so that it always works on > the _smallest_ exponent it has "in hand", work should be completed > reasonably quickly and in reasonable order. (Especially bearing in > mind that this scheme completes double-checking at the same time as > first tests!) Won't this mean systems constantly getting interupted in the middle of an exponent segment? Or would the systems only continue on one segment when they finish the current one? > When a prime is found, the discovery credit (& any prize money) > should obviously be split between the two users who ran the last > iteration on the exponent in question. This makes sense, though it might not be needed. This scheme would work best on people willing to stay with GIMPS for the decade required to finish the range. Many of these people have (fast) networks with lots of computers on them. The check/double check computers might be right next to each other, owned, and run by the same person. This will not matter for some time. Does anyone have current data for % mistakes? - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 15:20:14 +0200 (MET DST) From: Wojciech Florek <[EMAIL PROTECTED]> Subject: Mersenne: Average Machine Speed Hi all !! > > I hope they're at least running P166s by now. What's the average machine a > > GIMPSter runs, assuming that the average machine runs 24 hours a day? I > > remember it being P181 a while ago, I think. > > This brings up a very interesting question, what is the average speed of a > machine participating in GIMPS? Does PrimeNet have more data then the CPU type? > I would assume so. Can we get a breakdown of the average CPU speed of a GIMPS > producer and track this over time to see if we are keeping up with Moore's law? > > Can the average machine speed be tracked from previous data? Account for the > growth in the number of participating machines and come up with an average > machine speed from year to year? > > - -Marc > > > So, the important things I'll be working with are: > Total machines: 23252. P90 CPU Years/day, 7 day average: 62.058. > > However, years/day is an awkward unit to work with, so I'll convert it to P90 > days/day (i.e. how many P90s we'd need running at full tilt [constantly on] [snip] > for anything and is left constantly on for 24 hours a day with a P87.74 > processor. (Obviously by the machine tabulation above, the average GIMPSter > runs a significantly faster computer, but doesn't leave it on for 24 hours a > day). Eh? This is different than the old figure I remember. However, I > calculated that BEFORE I knew how many computers GIMPS had. So, I'll redo the > calculation based on accounts. > 14033 (accounts) * P_MegaHerta = 2,039,958 P1. > Solving here, we see that the average account is equivalent to a single > machine running at full tilt with a P145.37 processor. That's more like it. > > If I've had a major brain drain in my calculations, feel free to correct my > error on the list. > > S. "I want 2 million P1 processors!" L. > _________________________________________________________________ > I take a snap-shot of the PrimeNet TopProducers Awards time to time. (The last reported in my page was in July). I take such "shot" today Date/hour: 06 Aug 1999 11:04 Number of accounts: 12689 max value: 11661.340 (485.889) mean value: 39.362 ( 1.640) upper half mean value: 75.406 ( 3.142) median: 11.650 Of course, only the PrimeNet accounts are taken into account. Values in the parenthesis are expressed in P90 days per day units. So an average machine is 1.64*90=147.60 MHz (Pentium). If we assume that some accounts are nonactive than this average is a bit larger. E.g. the upper half of accounts give the average 3.142*90=282,78 MHz. The "real" value is somewhere in between. When George will update his top producers list (I think it'll happen on 8 or 9 Aug) I'll try to calculate average from his data. Note that TempleU-CAS (and some other teams) should be expressed in P90 years per day. Now it is about 485.889/365.25 approx 1.33 (!) or, in the other words, their set of machines works as one Pentium with 4.37 GHz CPU. A median - an account which occupies 6345 position - gives about Pentium 44MHz. Of course, all calculations assume 24 hours per day. I do not know the mean value of hours per day but it can be about 18-20. Therefore all results should be multiplied by a factor 24/20=1.2 through 24/18=1.33 what leads to a mean value 177-196 MHz (say 166-200 MHz, Pentium of course). Regards Wojciech Florek (WF) (Today at 489! I'm in the first 500! Wow!) Adam Mickiewicz University, Institute of Physics ul. Umultowska 85, 61-614 Poznan, Poland phone: (++48-61) 8273033 fax: (++48-61) 8257758 email: [EMAIL PROTECTED] www: http://main.amu.edu.pl/~florek _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 15:32:58 +0200 (MET DST) From: Wojciech Florek <[EMAIL PROTECTED]> Subject: Re: Mersenne: Average Machine Speed Hi! The question was "average machine speed". My answer (the previous mail) was rather "average account". Two extra notes: 1. PrimeNet statistics reads 14408 accounts. The Top Producers Awards has only about 12700 lines. I don't know why. 2. The last data give 14408 accounts, 23711 computers so the average (147MHz) should be divided by 23711/14408=1.645, so the average machine speed is 147/1.645 approx 90. Of course, the correction factor related with working hours of machines has to be applied again. Wojciech Florek (WF) Adam Mickiewicz University, Institute of Physics ul. Umultowska 85, 61-614 Poznan, Poland phone: (++48-61) 8273033 fax: (++48-61) 8257758 email: [EMAIL PROTECTED] www: http://main.amu.edu.pl/~florek _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 11:12:45 -0600 From: "Blosser, Jeremy" <[EMAIL PROTECTED]> Subject: RE: Mersenne: odd thought... (update) > -----Original Message----- > From: Blosser, Jeremy [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 05, 1999 4:32 PM > To: GIMPS (E-mail) > Subject: Mersenne: odd thought... > > > I know that OpenGL supports double precision matrix > transforms, and with > todays super duper 3D accelerator cards, wouldn't it be > possible to do an > FFT via OpenGL and take advantage of the 3d hardware? Or am I > completely off > my rocker. (as usual) :) > > I was just thinking about how you can run a program on just > about anything, > like, oh, a floppy controller, or whatever. Heck I was playing around > upgrading my Cisco 2900XL and noticed it uses a PPC603, (with > a whopping 4MB > of ram!) :) > > I guess the question really boils down to whether or not the > transforms are > handled by the hardware or not... (I dunno, graphics aren't > my sort of thing > baby). > Okay, so I took a little bit of time and looked into whether the current 3D cards support hardware transforms and the answer is for the consumer market, not quite yet... Apparently, nVidia (makers of the TNT/TNT2) have the NV10 coming out "this Fall" which has T&L (transform and lighting) support (basically geometry acceleration). So, I suppose that when that comes out, someone can benchmark how many flops it gets and then someone can try and write a client. Now, of course, you have the intergraph cards and SGI boxes (boxen?) which have super cool 3D accelerators in 'em which support geometry acceleration, so I suppose it would be feasable to code something for these that'd just plain rock... A good example would be the Intense3d Wildcat 4105 which does matrix transforms and the specs say 3000MFLOPS... I wasn't able to figure out what the precision is, but I'd imagine that it's double precision... So, if anyone wants to donate either an NV10 or some other hardware accelerated 3D card to me, I'll write the software for it. :) - -J P.S. Interesting article GIMPS is mention in from Wired News -- http://www.wired.com/news/news/technology/story/21136.html _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 06 Aug 1999 14:23:07 -0400 From: Marc Getty <[EMAIL PROTECTED]> Subject: Mersenne: GIMPS Coverage at Wired News Wired News, the online version of Wired Magazine, did a feature on 'CPU Contests' today. It has a lengthy write up about GIMPS, and compares it with distributed.net and Seti@Home. I should warn you, this is a bit of self promotion, I was mentioned in the article. See it at: http://www.wired.com/news/news/technology/story/21136.html - -Marc Marc Getty [EMAIL PROTECTED] Department of Dental Informatics, Temple University http://www.temple.edu/dentistry/di/ 215-707-8192 _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 15:32:46 -0400 From: Tom Goulet <[EMAIL PROTECTED]> Subject: Mersenne: redhat 6 - segfault Hi all! My apologies if this isn't the list for pesky technical problems regarding the GIMPS client. I grabbed the one specified for Red Hat 6.0, the filename (after gunzipping) is mprime-18.1-redhat6. I try to run it...Segmentation fault (core dumped) This happened with the other mprime.tar.gz package as well. Is this a known issue? Could my redhat installation be missing something that the client needs? (I have a lot of stuff not-installed.) In other news, I installed the client on slackware and it worked fine. :) (the mprime.tar.gz one) Any help? TomG _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 15:35:27 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Chirpy chirpy chirpy! Your English is quite good, by the way, better than many Americans'. ("Wha'sup, ma homie?" Obviously not his IQ.) <<When I start the programm on my notebook it makes a strange mechanical pulsing sound like an old damaged wheel or like an ill cricket.>> You say it doesn't come from your speakers, but _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 15:37:07 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Aaack. Please excuse the two messages I sent to the list just now - they were saved in my AOL "send later" pile, and I clicked Send All. Aaack. S. "Clicked the wrong button" L. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 17:17:53 -0300 (EST) From: "Nicolau C. Saldanha" <[EMAIL PROTECTED]> Subject: Re: Mersenne: redhat 6 - segfault On Fri, 6 Aug 1999, Tom Goulet wrote: > Hi all! > > My apologies if this isn't the list for pesky technical problems regarding > the GIMPS client. > > I grabbed the one specified for Red Hat 6.0, the filename (after gunzipping) > is mprime-18.1-redhat6. I try to run it...Segmentation fault (core dumped) > > This happened with the other mprime.tar.gz package as well. Is this a > known issue? Could my redhat installation be missing something that > the client needs? (I have a lot of stuff not-installed.) > > In other news, I installed the client on slackware and it worked fine. :) > (the mprime.tar.gz one) > > Any help? Not much help maybe, but I run it in more than one Red Hat 6.0 system, with no such problems. I get segfaults very consistently when the CPU fan breaks, to such an extent that I can use the program to detect this common hardware problem even in machines to which I have limited direct contact. http://www.mat.puc-rio.br/~nicolau _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 12:37:45 -0800 (AKDT) From: Siegmund <[EMAIL PROTECTED]> Subject: Mersenne: Moore's Law and Primenet The question was asked a few days back about whether the average machine speed of GIMPS participants was doubling every 18 months or not. I don't think we can really answer that question fairly, since we have new people joining with computers of various sizes and shapes all the time -- but if we just look at the average speed of primenet's computers, the answer is no, at least over the last 5 months. We've been moving backwards! CPU years/day/machine: CPU years/day/account: 20 March: .00309 .00533 09 May: .00303 .00534 20 June: .00278 .00470 26 July: .00272 .00455 Today: .00241 .00397 The percentage of Pentium II/Pros has risen from 43 to 47% over this time period, with a corresponding drop in the number of vanilla Pentiums. I left out April in an effort to avoid letting the v17 bug resets impact my figures. Kinda depressing when you look at how little we are gaining from the new accounts that have come into the effort the past couple months.... though it may well be there are machines that have not yet reported their first result and are dragging down the averages a bit. Gordon Bower _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 16:50:16 -0400 (EDT) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Subject: RE: Mersenne: odd thought... (update) On Fri, 6 Aug 1999, Blosser, Jeremy wrote: > Now, of course, you have the intergraph cards and SGI boxes (boxen?) which > have super cool 3D accelerators in 'em which support geometry acceleration, > so I suppose it would be feasable to code something for these that'd just > plain rock... A good example would be the Intense3d Wildcat 4105 which does > matrix transforms and the specs say 3000MFLOPS... I wasn't able to figure > out what the precision is, but I'd imagine that it's double precision... > > So, if anyone wants to donate either an NV10 or some other hardware > accelerated 3D card to me, I'll write the software for it. :) I seem to remember something like this being discussed before, probably on the RC5 list. I have *no* experience in this area, but don't video cards have proprietary firmware that's somehow burned into the card? And why would drawing pictures *need* double precision? I've also thought about e.g. putting a DSP and a few megs of memory on a PCI card...even for 32-bit fixed-point math those little guys just fly! Build a Schonhage-Strassen DWT, arrange things so that you DMA the next batch of data into the DSP's internal memory while crunching away on the present segment, and get out of the way :) You can even buy multiprocessor DSP boards that have ridiculous amounts of firepower on them. And then there are the weirdos who want to make laser printers crack RC5 keys, or (shudder) get Furbees to do it. jasonp _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 14:02:09 -0700 (PDT) From: poke <[EMAIL PROTECTED]> Subject: Re: Mersenne: redhat 6 - segfault That's interesting you say that. I used to have that problem ALL the time back when I used RH4.X. After I graduated from college I didn't use Linux until RH5.2 came out and it worked great there. I wonder if the old problem is cropping up again. - -Chuck On Fri, 6 Aug 1999, Tom Goulet wrote: > Hi all! > > My apologies if this isn't the list for pesky technical problems regarding > the GIMPS client. > > I grabbed the one specified for Red Hat 6.0, the filename (after gunzipping) > is mprime-18.1-redhat6. I try to run it...Segmentation fault (core dumped) > > This happened with the other mprime.tar.gz package as well. Is this a > known issue? Could my redhat installation be missing something that > the client needs? (I have a lot of stuff not-installed.) > > In other news, I installed the client on slackware and it worked fine. :) > (the mprime.tar.gz one) > > Any help? > > TomG > > _________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : WWW: http://www.silverlink.net/poke : : E-Mail: [EMAIL PROTECTED] : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Ask Mike! Aviation's response to Dear : : Abby. http://www.avstarair.com : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 6 Aug 1999 22:22:50 +0100 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Multiple residues - enhancing double-checking On 6 Aug 99, at 2:47, Lucas Wiman wrote: > The main way to speed this up is to have system C continue from the last > residue that it is known that system A and B agree upon. The way I looked at it, the PrimeNet server only has to store _one_ (64 bit) residue for each exponent in progress. As others have pointed out, shifting files >> 10 MB in size across slow dial-up links isn't going to be popular, but you can't have C continue from the last residue agreed by A and B, unless the agreed residue is known to the PrimeNet server. 10000 users by 16 MB per file = 160 GB of disk space - I think Scott might have to invest in a new disk array! > Or, possibly > even better (though more error prone) would be to have A and B recalculate > from last agreed upon residue, and see if they now agree. Now, that's a possibility. But suppose they don't, again. It's possible that this could happen if one of the systems was sufferring from an esoteric hardware bug (possibly common to both systems, but they'd be running different offsets, so the FFT data would differ). My "inefficient" scheme also allows reasonably quick recovery from one of the systems disconnecting from the project. > > Won't this mean systems constantly getting interupted in the middle of an > exponent segment? Or would the systems only continue on one segment when > they finish the current one? No - if I've exponent x suspended & I'm working on exponent y ( > x), then I just wait until I'm checking in y anyway, when I may get a message to continue x (or some other exponent(s)). If I don't, and y is now suspended too, I need another exponent to start work on. If I find I have several exponents all of which are now OK to continue, I just pick the numerically lowest one to work on next. > > This makes sense, though it might not be needed. This scheme would work > best on people willing to stay with GIMPS for the decade required to > finish the range. Many of these people have (fast) networks with lots of > computers on them. The check/double check computers might be right next > to each other, owned, and run by the same person. A couple of points here: (1) Can anyone honestly commit to a project for a whole decade? (2) I honestly think it's better if the two computers working on a particular exponent are _not_ owned/operated by the same person. This precaution removes the possibility of one deranged individual "contaminating" the project results by "forging" results. Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 09:37:00 -0400 From: "Olivier Langlois" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Chirpy chirpy chirpy! This is a multi-part message in MIME format. - ------=_NextPart_000_006A_01BEE181.90A7CF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit - -----Original Message----- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 6 ao�t, 1999 16:09 Subject: Mersenne: Chirpy chirpy chirpy! >Your English is quite good, by the way, better than many Americans'. >("Wha'sup, ma homie?" Obviously not his IQ.) > ><<When I start the programm on my notebook it makes a strange mechanical > pulsing sound like an old damaged wheel or like an ill cricket.>> The sound does come from the speakers. The same thing is happenning on my computer. When I first installed Prime95 last summer, I was beleiving that the sound was coming from a cricket that was near my window outside. It took me few months (the cricket theory couldn't hold anymore in the Winter :-) to understand that it was caused by the CPU activity generated by Prime95. > >You say it doesn't come from your speakers, but >_________________________________________________________________ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers - ------=_NextPart_000_006A_01BEE181.90A7CF20 Content-Type: text/x-vcard; name="Olivier Langlois.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Olivier Langlois.vcf" BEGIN:VCARD VERSION:2.1 N:Langlois;Olivier FN:Olivier Langlois ADR;HOME:;;;Montreal;Quebec;;Canada LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Montreal, Quebec=0D=0ACanada URL:http://www3.sympatico.ca/olanglois EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:19990808T133700Z END:VCARD - ------=_NextPart_000_006A_01BEE181.90A7CF20-- _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 07 Aug 1999 16:10:11 +0200 From: Sturle Sunde <[EMAIL PROTECTED]> Subject: Re: Mersenne: redhat 6 - segfault > I grabbed the one specified for Red Hat 6.0, the filename (after gunzipping) > is mprime-18.1-redhat6. I try to run it...Segmentation fault (core dumped) Probably some libc/glibc conflict. Try the staticly linked version (sprime.tar.gz). - -- Sturle URL: http://www.stud.ifi.uio.no/~sturles/ Er det m}ndag i dag? ~~~~~~ MMF: http://www.alladvantage.com/go.asp?refid=BUP399 - St. URLe _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 7 Aug 1999 11:59:17 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Chirpy chirpy chirpy! (Heh, full message this time) <<The sound does come from the speakers. The same thing is happenning on my computer. When I first installed Prime95 last summer, I was beleiving that the sound was coming from a cricket that was near my window outside. It took me few months (the cricket theory couldn't hold anymore in the Winter :-) to understand that it was caused by the CPU activity generated by Prime95.>> I had _no_ idea what it was originally, so I had to ask around. I'm still not sure what causes it, and there doesn't seem to be a single, universally accepted explanation for it. All I know, is that on my poor old 486 DX 33MHz with 4MB RAM, accessing its hard drives would generate clicks and chirps through its 8-bit SoundBlaster card, and starting Windows 3.1 would _really_ get the chirping going. Now, only Prime95 causes chirps on my Pentium 200 with a SoundBlaster clone. And others have the same chirps with much different (and better) hardware, so it's can't really be a weird anomaly, in my opinion. The chirping also changes speed with the level of CPU usage I put on my computer, and it _seems_ to be one chirp per iteration. S. "I liked it better with 4136613 when it did chirpchirpchirp and not now with 7-something, cause it does chirp......chirp......chirp...." L. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 7 Aug 1999 10:36:21 -0700 From: Paul Leyland <[EMAIL PROTECTED]> Subject: RE: Mersenne: Multiple residues - enhancing double-checking > From: Brian J. Beesley [mailto:[EMAIL PROTECTED]] > A couple of points here: > (1) Can anyone honestly commit to a project for a whole decade? Yes, they can and do. In the field of computational number theory, several participants in the Cunningham project have been active much longer than my decade. Sam Wagstaff has been co-ordinating it longer than that. To be honest, I don't know when he started. Perhaps Peter Mon tgomery (another long-time participant) can inform us, as I know he's also on the Mersenne list. In other fields, it's not unusual to commit to a decade or more. Consider the deep space missions such as Voyager, or the astronomers who monitor a particular class of objects for most of their working lives. I know some amateurs who have been observing particular variable stars since the 1960's; George Alcock has been searching for comets and novae since the late fifties. Paul _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 7 Aug 1999 21:50:07 +0200 (MET DST) From: [EMAIL PROTECTED] Subject: RE: Mersenne: Multiple residues - enhancing double-checking Paul Leyland (whom I'll meet for the second time later this month) writes: > > From: Brian J. Beesley [mailto:[EMAIL PROTECTED]] > > > A couple of points here: > > (1) Can anyone honestly commit to a project for a whole decade? > Yes, they can and do. In the field of computational number theory, several > participants in the Cunningham project have been active much longer than my > decade. Sam Wagstaff has been co-ordinating it longer than that. To be > honest, I don't know when he started. Perhaps Peter Mon tgomery (another > long-time participant) can inform us, as I know he's also on the Mersenne > list. > In other fields, it's not unusual to commit to a decade or more. Consider > the deep space missions such as Voyager, or the astronomers who monitor a > particular class of objects for most of their working lives. I know some > amateurs who have been observing particular variable stars since the 1960's; > George Alcock has been searching for comets and novae since the late > fifties. Ten years for one computation seems a long time. Yes, I have been contributing to the Cunningham project for a long time, using machines at multiple institutions, but we can hardly commit for ten years. Jobs change today, at least in the USA. A home machine may be stolen or damaged by fire or floods. My family wouldn't know what to do if I died. For the very long LL computations, it is reasonable for two sites A and B to start the computation, and do a checkpoint perhaps every 1000 iterations. When A reaches its 7000-th iteration (or other multiple of 1000), it sends the checkpoint file to a central site, and can continue for another 1000 iterations if B has submitted a consistent checkpoint for the 6000-th iteration, with different programs used for iterations 5001-6000. Otherwise A is blocked (i.e., told to do something else until B catches up). If A and B differ at the 6000-th iteration checkpoint, or if one times out (say six months with no activity), a third site can restart from the (agreed) 5000-th iteration checkpoint It is important that the different programs (e.g., Prime95, MacLucas, LucasMayer) agree on a common checkpoint format. Not only must the central server be able to compare them, but a contributor might migrate from a Pentium in 1996 to an Alpha today to a Merced in 2002. Of course this data at the central site will be voluminous, if each exponent around 100 M averages 2.5 13 Mb checkpoint files (for iterations 5000 and 6000 and possibly 7000 in the example). If there are 100000 LL tests in progress, then the central site will need 3250 Gb. A tetrabyte is huge today but may be common in 15 years. In the 1970's much data was on seven-track tapes. I recall each held 1.9 M 60-bit words (14 Mb) Today the NFS data for M619 is being processed on a filesystem with 16 Gb, a 1100-fold increase over 25 years. Optimizations can reduce the size stored. For example, store the full 5000-th iteration checkpoint, but only hash(6000-th iteration) and hash(7000-th iteration) where the hash function might return only 1024 bits. When the second site sends a 6000-th iteration checkpoint, verify that it gives the same hash value. If yes, then we assume B's full file agrees with A's, and store the 6000-th iteration checkpoint while deleting the 5000-th. If no, the full 5000-th remains available for a third site to use. Peter _________________________________________________________________ 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 #611 ******************************
