Mersenne: Re: build-it-yourself Athlon
On 16 Apr 2001, at 16:27, Ernst Mayer wrote: Fry's (a big local discount computer electronics chain) has a great deal on build-it-yourself Athlons (US$ 350 for 1.2GHz CPU, MB, case, floppy, ethernet card, 56K modem video card) so I'm going to take the plunge. Does sound like a good bargain... Are you _sure_ this includes the processor? Tip, buy the best heat sink you can find, even if you have to throw away the one supplied. And install an extra case fan. BTW there are now two variants of Athlon (Thunderbird) processor, with 200 MHz (100 MHz DDR) or 266 MHz (133 MHz DDR) front-speed bus. Since the multiplier is fixed, you want to make sure you have the correct type for your motherboard. Some motherboards are switchable for FSB, but, if you install a 266 MHz FSB CPU in a M/B running at 200 MHz FSB, the system will run at only 3/4 of its rated speed. Which will slow it down to about the same speed as a PIII running at the same rated speed. The key is the last character of the part type stamped onto the die. A 200 MHz FSB CPU ends with B whilst a 266 MHz FSB CPU ends with C. Unfortunately you won't easily be able to read this if you have bought a system with the heat sink already stuck onto the processor. The one question that remains is whether to buy ECC or non-ECC memory? Neither is terribly expensive (256MB of Athlon-compatible PC133 memory goes for $45 non-ECC, $90 ECC at pricewatch.com), but I don't want to pay extra unless I'm sure it will give some definite advantage. So the question is: does ECC memory of this kind actually do active error correction, or merely detection? Actually there are several questions here... Memory described as ECC should actively correct single-bit errors and detect most multi-bit errors. If an uncorrected error is detected, it should raise non-maskable interrupt, which (depending on the OS) will probably cause a kernel panic (or BSOD on a Windows system). If an error is detected and corrected, the memory should raise a different interrupt, which the OS may ignore, or log somewhere. My understanding is that the correction is actually done in the DIMM itself, but depends on the appropriate signals being supplied by the chipset. The only experience I have of a corrected memory error on a PC-type system was on a 486 running linux kernel 2.2.x (using old FPM SIMMS); the error was logged in /var/log/messages the system sailed happily on for months afterwards. Something similar should happen if you have the CPU cache ECC enabled. However, whether this works or not depends on the chipset as well as the BIOS settings and the OS. Note that the VIA chipsets often supplied on Athlon motherboards do NOT support ECC; if you install ECC memory, it functions as non-parity memory. I much prefer ECC memory, but there is absolutely _no_ point in paying extra for ECC memory if the capability is non-functional due to deficiencies in the chipset. However it is definitely worth paying the small amount extra for faster memory (PC133 instead of PC100, even if the memory bus is running at 100 MHz, or CL2 instead of CL3) since this can and usually does significantly benefit system performance - though some tuning of chipset memory timings through BIOS may be necessary. If OTOH one only gains the ability to *detect* errors, is Mprime configured with this in mind, i.e. will it restart from the last savefile if a memory error is detected? Not relevant - mprime will not be aware of a corrected memory error, whilst a kernel panic will crash the system, so mprime have to restart from the last savefile (once you've stood the system up again!) Even if the system crashes whilst mprime is writing a savefile you should be OK, since the savefile is renamed to something mprime will look for only after the file has been written successfully. Even with full ECC capability, there _could_ still be an uncorrected, undetected error - but this would have to be multi-bit, and therefore rather rare. The chance of this happening without there being a high rate of corrected errors must be rather small. BTW if you're looking for a x86 linux distribution, I'd strongly suggest you look at "Rawhide" which is the beta for RedHat 7.1. This comes with an apparently functional reasonably stable kernel (v2.4.2 last time I looked); there are _major_ advantages in running a v2.4 kernel on an x86 system (support for UDMA66 UDMA100 disks, built-in I2C support which is useful for CPU temperature sensing, etc.). But the real point is that it's a lot easier to install Rawhide from scratch than it is to do an install of RH 7.0 then upgrade the kernel. I have little experience of distributions other than RedHat, but I have little doubt that the same principles apply. Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ --
Re: Mersenne: Re: build-it-yourself Athlon
Fry's (a big local discount computer electronics chain) has a great deal on build-it-yourself Athlons (US$ 350 for 1.2GHz CPU, MB, case, floppy, ethernet card, 56K modem video card) so I'm going to take the plunge. those motherboards in those starter kits tend to be JUNK. ... The one question that remains is whether to buy ECC or non-ECC memory? Neither is terribly expensive (256MB of Athlon-compatible PC133 memory goes for $45 non-ECC, $90 ECC at pricewatch.com), but I don't want to pay extra unless I'm sure it will give some definite advantage. So the question is: does ECC memory of this kind actually do active error correction, or merely detection? Does the mobo even support ECC? Its a function of the chipset *and* the system BIOS. I'm not aware of any VIA type motherboards having any sort of parity or ECC capability. Actually there are several questions here... Memory described as ECC should actively correct single-bit errors and detect most multi-bit errors. If an uncorrected error is detected, it should raise non-maskable interrupt, which (depending on the OS) will probably cause a kernel panic (or BSOD on a Windows system). If an error is detected and corrected, the memory should raise a different interrupt, which the OS may ignore, or log somewhere. The standard for Hamming code based ECC is correct single bit, and detect double bit errors. more than 2 bits wrong will probably have a ~50% chance of being caught, or possibly mask as a different single bit error and get incorrectly corrected. An uncorrectable error will be treated as a parity error, and either hard halt the box, or cause an abrupt reboot. My understanding is that the correction is actually done in the DIMM itself, but depends on the appropriate signals being supplied by the chipset. No, the correction is done in the chipset. the ram is simply 72 bits instead of 64 bits wide enabling ECC generally adds a clock penalty to every write too, so it slows things down considerably. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: [Fwd: Plug into peer-to-peer philanthropy with Intel]
"A linux version is under development" they claim. Why don't they just recompile it with entropia hooks? -- edited --- Intel Home Computing Newsletter Delivering Intel technology to your inbox April 2001 Revolutionary technology, a new Web resource, and a great deal from Shop Intel(SM)! Find out in this issue how Intel is developing innovative ways for you to use your computer and the Web. -- Plug into 50 Teraflops of computing power to help find a cure * Plug into 50 Teraflops of computing power to help find a cure * Sign up today for the Intel Philanthropic Peer-to-Peer Program that harnesses the power of your PC to help scientific researchers discover cures for major diseases. Using a peer-to-peer computing model, the program utilizes the Internet to turn the unused computing power of millions of individual PCs into one of the largest computing resources in history. With a goal of registering 6 million people, the program would produce the equivalent of 50 Teraflops of super computing power, with 1 Teraflop equating to 1 trillion floating point operations per second. There's no cost, no catch, and no noticeable impact on your computer's performance, because the program only takes advantage of the processing power you're not using at the time. Make scientific history by downloading the program at intel.com/cure. Or find out more about the program now. *Legal Information and Privacy Policy 2001 Intel Corporation _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne Digest V1 #840
Mersenne DigestTuesday, April 17 2001Volume 01 : Number 840 -- Date: Sun, 15 Apr 2001 14:12:22 +0200 From: Alexander Kruppa [EMAIL PROTECTED] Subject: Mersenne: A factor of the 31st Fermat number 46931635677864055013377 divides 2^(2^31)+1 On Thursday, 12. April 2001, a factor of the 31st Fermat number (F_31) was discovered, thus proving that F_31 is composite. Since the primality proof by Crandall, Mayer Papadopoulos, which showed F_24 to be composite, F_31 was the smallest Fermat number whose primality status was unknown. That distinction now goes to F_33; a detailed list of known factors and primality status of Fermat numbers can be found at http://www.prothsearch.net/fermat. The factor was found by Alexander Kruppa on one of five AMD Thunderbird 1GHz computers located at the Technische Universitaet Muenchen. The program that was used is MFAC, written by Tony Forbes. To find a divisor of F_m, MFAC computes a list of numbers of the form (Q*k + h)*2^m + 1, where Q is 4*(2*3*5*..*q) and q is a small prime. In our case, q=11 was used. MFAC chooses h so that gcd(h*2^e + 1, Q) = 1. Composite numbers are eliminated from the list by sieving all multiples of small primes, in our case all primes = 611999. Each remaining candidate factor d is then tested by verifying the condition 2^2^n == -1 (mod d), for n = m + x, where x is the greatest integer so that 2^(x+2) | (Q*k + h). It took about 2 weeks to find the factor on the five available machines. The discoverer had checked the range up to k=10^9*2310, where k*2^33+1 is the candidate divisor, on different hardware before (as have other searchers before him) and then assigned subintervals of size 2*10^8*2310 to each machine in turn. At k=5463561471303, the factor was found. At that point, about 2.3*10^11 trial divisions with candidate divisors had been performed, while about 9*10^11 candidate divisors had been eliminated by sieving. The cofactor has 646456971 decimal digits, its primality status is unknown. We would like to thank the staff of Lehrstuhl XIII, Systemarchitektur und Betriebssysteme, an der Technischen Universitaet Muenchen, in particular Christian Rehn, for granting use of their computer hardware. Alexander Kruppa would like to dedicate the discovery to his father, Andreas Kruppa, who passed away while Alexander was making a first contact to Fermat number research by helping with the computation for the F_24 compositeness proof. Alexander Kruppa [EMAIL PROTECTED] Tony Forbes [EMAIL PROTECTED] _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Mon, 16 Apr 2001 17:03:14 +0800 From: "Dave Mullen" [EMAIL PROTECTED] Subject: Mersenne: O.T. ? Factoring N with MPQS This is a multi-part message in MIME format. - --=_NextPart_000_0026_01C0C697.203242A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been playing around with MPQS on UBASIC, to see if I could find a = factor of M727 and/or RSA232 ... First I tried the approach of using very large factor bases ... i.e. I'd = sieve to 131071 using UBASIC's PRMDIV function, then check the remaining = residues up to about 2^48 using P-1 ... after testing 2^32 numbers, I = had a couple of full-relations, useless combinations ... When dealing with numbers of this magnitude, that kind of sieving needs = to be done on distributed-computing platforms, with hundreds of machines = taking little sections to sieve and reporting back to a main server ... = like PrimeNet etc. So then I tried a different approach of using a much smaller factor = base, and looking only for partials / double partials ... For the formula F(x) =3D a2x2 + 2abx + c, where b2 - N =3D a2c, and = checking over the range x =3D 0 to x =3D 2^32-1 ... First I look for F(n) where it is the product of small primes x one = large prime P (proved by pseudo-primality testing on a few bases), For each P, I find the two roots n1,n2 =3D=3D 0 mod P for F(x), For n1,n2, then n1+P, n2+P, n1+2P, n2+2P, n1+3P etc I checked F(m) where = it is product of small primes x P x one other large prime Q (again = proved by pseudo-primality testing), Then I scan through the resulting list looking for two results with = different n and P, and the same Q ... =20 So I end up with some Partial Relations thus f --- some small primes x P1 g --- some small primes x P2 h --- some small primes x P1 x Q j --- some small primes x P2 x Q And a bit of work ... Uf =3D a2f + b, Vf =3D a2 x some small primes x P1 Ug =3D a2g + b, Vg =3D a2 x some small primes x P2 Uh =3D a2h + b, Vh =3D a2 x some small primes x P1 x Q Uj =3D a2j + b, Vj =3D a2 x some small primes x P2 x Q Then, multiplying the relations
Mersenne: Juno Warning
Someone on this list earlier warned about Juno using subscriber's computers. Here is a portion of the current Juno Virtual Supercomputer Project data. "The idea behind the Juno Virtual Supercomputer Project is simple. Today, researchers who have large, computationally demanding problems to solve often tackle them by running them on a "supercomputer," which is a computer facility that might be as powerful as several thousand separate personal computers. Juno plans to offer such researchers an even more powerful tool, by dividing such problems into a number of smaller, simpler problems, then downloading each small problem to a Juno member's computer (in much the same way that we currently download e-mail and advertisements to our members' computers) to solve. The member's computer will work on solving the small problem by running various mathematical calculations during time when the computer would otherwise be idle. These calculations will be performed only when the computer's screen saver program is running, and never when the member is using the machine. Once the problem is solved, the solution will be stored temporarily on the member's computer, then delivered to Juno during the member's next connection to our central computers (much as Juno currently stores and delivers your responses to the ads you see on the service). "I use Juno's free basic servicedo I have to participate in the Juno Virtual Supercomputer Project?" Participation in this initial phase is strictly voluntary. At some point in the future we may require some or all users of our free service to participate as a condition of using the service for free, but we expect to use volunteers to supply the computational power required for the project's initial activities. If we do make participation mandatory for free subscribers in the future, we will notify any affected subscribers by e-mail, and would expect to offer them the alternative of upgrading to one of our billable premium services if they prefer not to participate in the project. "I'm a paying subscriber to one of Juno's premium servicesdo I have to participate in the Juno Virtual Supercomputer Project?" No. Even if we decide at some point to require some or all users of our free basic service to participate in the project, we do not expect such a requirement to apply to our paying subscribers, whose participation is expected to remain strictly optional. "Should I be worried about Juno downloading data and software to my computer?" No. Juno has been downloading data and software to your computer since the day you first subscribed. Ads, for example, are already temporarily stored on your hard drive in preparation for display at times when you're not connected to Juno's central computers, just as scientific problems and data would be temporarily stored on your hard drive if you decide to participate in the Juno Virtual Supercomputer Project. Software is already downloaded for execution on your machine to allow you, for example, to respond to a promotional offer by one of our advertisers, and such responses may then be uploaded to our central computers the next time you connect to the service, in a manner analogous to the downloading of scientific problems and the uploading of results as part of the Juno Virtual Supercomputer Project. From time to time, we also download new versions of the Juno software to bring your version up to date, and we expect to download new scientific software from time to time as part of the Juno Virtual Supercomputer Project. In short, we have downloaded data and software to literally millions of people over the past five years, and have consistently done so successfully, without causing problems to our users' computers. If you decide to participate in the Juno Virtual Supercomputer Project, the main difference will be that the software and data downloaded to your computer will be used not only to support the Juno service and ad system, but also to allow your computer to perform its share of the calculations involved in various scientific problems, and to save the results of these calculations so they can be reported back to our central computers. "If I participate in the Juno Virtual Supercomputer Project, will my computer have to stay connected to the Internet all day? Will I have to be online for my computer to contribute to the project's supercomputing activities?" No. To participate in this project, your computer will only have to connect to Juno's central computers for relatively short periods of time, roughly comparable to the connections you currently make when you send or receive e-mail. The actual work of solving the problem can take place even when you're not connected to the Internet. "Do I have to leave my computer on all day?" No, but the Juno Virtual Supercomputer Project can make use of your computer only if it is turned on, so the longer you keep your computer turned on, the more you'll contribute to the project. At
Re: Mersenne: Juno Warning
On Tue, 17 Apr 2001 17:49:49 -0700, Aaron Blosser wrote: "Should I be worried about Juno downloading data and software to my computer?" No. Juno has been downloading data and software to your computer since the day you first subscribed. Gotta give 'em credit for being honest. Dang, I shoulda thought of that. :( No, no, no, you just don't understand! Yes. In general, we expect to charge for (or perhaps to derive other forms of commercial benefit from) the use of the Juno Virtual Supercomputer Project, and hope that any fees derived from such use will help us cover the cost of providing our services to you and the millions of other people who use them. And, to think - all that money that all the other 'free' ISPs are losing by not selling time on the CPUs of their customers! Maybe you should have looked for a job with them back in the day? Forget 3,000 machines - there's "millions of other people" out there who won't even notice their computers being used in liu of nineteen dollars a month for dialup access, usually capped at 28K and very flakey, accourding to the folks I know who use such ISPs. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Juno Warning [Somewhat OT]
On Tue, 17 Apr 2001 19:25:45 -0400, Vincent Mooney wrote: Someone on this list earlier warned about Juno using subscriber's computers. Here is a portion of the current Juno Virtual Supercomputer Project data. (BIG snip) No. Juno has been downloading data and software to your computer since the day you first subscribed. Only a truly professional ISP would discuss - in an official webpage - their techniques for "downloading to" a computer. From time to time, we also download new versions of the Juno software to bring your version up to date, and we expect to download new scientific software from time to time as part of the Juno Virtual Supercomputer Project. NO mention of security, NO mention of encryption, targeted to Windows 9x users - truly impressive. "Do I have to leave my computer on all day?" (snip) At some point in the future, we may begin requiring people who participate in the project to leave their computers turned on for some minimum amount of time (or possibly all the time) I wonder how the costs connected with doing so (electricity, air conditioning in the summer, possible damage to extremely overclocked systems) compare with the cost for a minimal dialup account - or for that matter with switching to excite, bluelight, ifree, netzero, or one of the other adware ISPs. The only time your computer might initiate a connection is if a computational problem is downloaded to your computer when you establish one connection to Juno's central computers, then don't dial in again for a long time. Fourth mention of "downloading to" client computers. I doubt this is just confusion - 'downloading' is usually something web users do voluntarily. Even in that case, your computer would only dial one of the access numbers you've previously selected, connect to Juno's own central computers (not to the open Internet), and stay connected long enough to deliver the results of its computations (and any e-mail you may have received since your last connection, etc.). We don't expect this sort of "automatic connection" to occur frequently, if ever, but it is possible that we might at some point use this feature under certain circumstances (for example, if we believed the results of an important computation might otherwise be likely to go unreported indefinitely). Or, more accurately, when we feel that it will cost us less to dial in than to wait on payments from those we are selling computer time to. Nathan _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Juno Warning [Somewhat OT]
On Tue, 17 Apr 2001 20:25:04 -0700, Aaron Blosser wrote: From time to time, we also download new versions of the Juno software to bring your version up to date, and we expect to download new scientific software from time to time as part of the Juno Virtual Supercomputer Project. NO mention of security, NO mention of encryption, targeted to Windows 9x users - truly impressive. This also begs an interesting question of what happens if the "scientific software" conflicts with something on your system. As much as I just love GIMPS, there is one interesting little bugaboo that I don't know if it's been mentioned: Anyone else out there use Netmeeting to do videoconferencing? If so, have you noticed that if NTPRIME (the NT service version) is running, your video will go REALLY REALLY slow? I don't know of Prime95 has the same effect or not, but I'd guess so. I wouldn't know, not having a need to do videoconferencing. However, many other projects (not GIMPS) have a need to write to disc at fairly frequent intervals; this can require stopping those projects (and, in my case, starting GIMPS - I run it 90% of the time, but not always) when you need to defragment or run another utility that demands full access to the disc. So again, what happens if Juno's software starts interfering with your other apps, even when your not connected? That's a very good question. If nothing else, on a system with, say, 32 MB of memory, even the memory footprint of the Juno program might become a problem. It would be possible, I imagine, to engineer the Juno program in such a way that any attempt to stop it with a task management utility hangs the system; I believe some of the web-filtering programs now use that trick. Is it even fair that your free internet connection would actually use your computer even when you're not using your free connection? Even the Juno banner ads only show up while you're actually online. Imagine if Juno said those ads would now show up all through the day whether you're dialed in or not. To be fair, many consumer programs now remain running (albeit using minimal CPU) by default. AIM, Realplayer and ICQ are only the first examples to come to mind, and in some cases it took me half an hour to figure out how to stop the automatic starting. I know many people who just leave those things running out of ignorance. The only time your computer might initiate a connection is if a computational problem is downloaded to your computer when you establish one connection to Juno's central computers, then don't dial in again for a long time. Fourth mention of "downloading to" client computers. I doubt this is just confusion - 'downloading' is usually something web users do voluntarily. They should call it a "push install" or something, whereas you're right, downloading is more of a pull (user initiated). Besides various incidents in the past, I am in the biz of doing software installs on large networks, and that's the general terminology we'd use for a server based install being forced on clients: a push. If it's advertised to workstations but not mandatory, pull is appropriate. I don't know the terminology usually used in the industry. That said, most consumer programs that I know of don't automatically update themselves. Many programs (AIM, Napster, Realplayer, Winamp and some games in my personal experience) connect, and pop up a window suggesting an upgrade, but don't force it on the user (never mind get online specifically to carry out a scheduled upgrade!) The one exception that I know of is AOL; some weeks ago, a friend of mine and I were talking over IM when she suddenly stopped responding; as it happened, she was home for the weekend and her AOL client suddenly decided to lock up its main window, download an upgrade, get offline, install said upgrade and then inform my friend that she needed to reboot before getting back online. I don't know to what extent the purpose of the upgrade was explained to my friend, and you can imagine how she felt. Now imagine how she would have felt if she was, say, typing a 3-page email through ssh at the time the upgrade was shoved down her throat. And even then, we have to be careful. Some installs require a reboot. If they update your "scientific software" and it needs to reboot, that could be annoying. And then software compatibility issues... eech. At least the GIMPS software is simple enough to deal with those things, but not all programmers are as savvy as dear George. Also, a lot of programs require far more registry support that GIMPS does. Aaron Nathan _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
