Mersenne Digest Thursday, September 13 2001 Volume 01 : Number 883 ---------------------------------------------------------------------- Date: Mon, 10 Sep 2001 19:44:31 -0700 From: Bob Margulies Subject: Mersenne: Multithreaded? >Date: Mon, 10 Sep 2001 19:56:51 -0400 >From: Nathan Russell ?Subject: Re: Mersenne: Prime Net Server >On Mon, 10 Sep 2001 19:56:34 +0200, "Jörg Thomsen" >wrote: > >Hi, > >it isn't that easy at all. The default parameter for >networkretries is, afaik, 10 minutes. So >most clients try to connect every 10 minutes until thy got a >timeout. And the timeout seems to be very long :-/. >I think we loose much power on these gimpsserver fails. > > > Regards > Jörg >However, AFAIK, the client continues working while it is trying to >connect; it's multithreaded. That wasn't my experience. During the outage, I'd get the message that it was trying to contact the server. Then it would sit there for 6 minutes, doing nothing, then state that it would try again in an hour, then pick up where it left off. That 6 minutes per hour was a loss of 10% for 2 days. So don't know what Nathan means by "multithreading." And, BTW, why does it take 6 minutes to give up? Wouldn't 1 minute be sufficient? _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 10 Sep 2001 23:16:26 -0400 From: Nathan Russell Subject: Re: Mersenne: Multithreaded? On Mon, 10 Sep 2001 19:44:31 -0700, Bob Margulies wrote: > >That wasn't my experience. During the outage, I'd get the message that >it was trying to contact the server. Then it would sit there for 6 >minutes, doing nothing, then state that it would try again in an hour, >then pick up where it left off. That 6 minutes per hour was a loss of >10% for 2 days. I can't speak to some of your other questions, but I can offer a suggestion for that one. If you select 'do not communicate automatically' in the advanced->manual communication dialogue box, the client will wait for you to ask it to communicate. I do the same here at college, since the firewall automatically blocks off my access to off-campus sites 8 hours after I last log into it. I also must initiate all connections regardless, but this doesn't impact GIMPS (or, in my opinion, any sane distributed computing client). Nathan _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 11 Sep 2001 16:45:18 -0700 From: Gerry Snyder Subject: Mersenne: Seeming problem with mprime 21.3 (ECM too fast?) I just upgraded my linux box mprime to 21.3. The machine is a dual P3. One CPU has been running LL, and the other factoring (currently ECM). I have been starting mprime with a shell script, putting each execution in an xterm, using the -m option to get the -d printout and make it easy to interrupt execution and query the status. With mprime 20.x both CPU's were devoting more than 98% of their time to mprime. Now during one phase of ECM a lot of CPU power (>50% at times) is going to X and xterm. Is it just that 21.3 is running ECM so much faster that its output takes up significant resources, or is there more to it? I have switched to running without -m or -d options, but is there an easy way to get more visibility without the big slowdown? All advice welcome. Gerry - -- mailto:gerrysnyder@mediaone.net _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 12 Sep 2001 15:44:44 +0100 From: "David Jaggard" Subject: Mersenne: Torture test passes but normal use fails! This is a multi-part message in MIME format. - --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F8_01C13BA1.D848AEE0" - ------=_NextPart_000_00F8_01C13BA1.D848AEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Mailing List, Could somebody give me some advice? I have an overclocked AMD Duron machine using windows 98SE running at = just under 1GHz and have been running prime95 v20 successfully for many = months. I have occasionally had hardware errors when I have tried to = overclock further but at the current speed prime95 v20 is happy. Yesterday (11-09-2001) I upgraded prime95 from v20 to v21. My tests = ressumed only to quickly fail with a SUMOUT/possible hardware failure. I = made some small changes to speed and core voltage but could not correct = the errors. I decided to run the torture test and I left it running all = night. This morning I viewed results.txt and all tests had passed yet = the normal operation of the program still fails. Surely if my system was = unstable the torture test should fail! Is it possible that in the new = release the normal primality tests are more stressful than the torture = test? Or is there a bug? On a seperate matter why is there no processor catagory for AMD Duron = chips and yet there is a catagory for Intel Celerons? I'm proud of the = fact that my budget setup is faster than some ready-made Athlon 1GHz = systems! Thanks in advance for any feedback Davy - ------=_NextPart_000_00F8_01C13BA1.D848AEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Mailing List,
 
Could somebody give me some = advice?
 
I have an overclocked AMD Duron machine = using=20 windows 98SE running at just under 1GHz and have been running prime95 = v20=20 successfully for many months. I have occasionally had hardware errors = when I=20 have tried to overclock further but at the current speed prime95 v20 is=20 happy.
 
Yesterday (11-09-2001) I upgraded = prime95 from v20=20 to v21. My tests ressumed only to quickly fail with a SUMOUT/possible = hardware=20 failure. I made some small changes to speed and core voltage but could = not=20 correct the errors. I decided to run the torture test and I left it = running all=20 night. This morning I viewed results.txt and all tests had passed yet = the normal=20 operation of the program still fails. Surely if my system was unstable = the=20 torture test should fail! Is it possible that in the new release the = normal=20 primality tests are more stressful than the torture test? Or is there a=20 bug?
 
On a seperate matter why is there no = processor=20 catagory for AMD Duron chips and yet there is a catagory for Intel = Celerons? I'm=20 proud of the fact that my budget setup is faster than some ready-made = Athlon=20 1GHz systems!
 
Thanks in advance for any = feedback
 
Davy
- ------=_NextPart_000_00F8_01C13BA1.D848AEE0-- - --------------InterScan_NT_MIME_Boundary-- _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 12 Sep 2001 18:03:00 +0200 From: Canart Jean-Yves Subject: FW: Mersenne: Torture test passes but normal use fails! This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13BA4.6547BC80" - ------_=_NextPart_001_01C13BA4.6547BC80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had the same problem on my overclocked Athlon that started to produce SUMOUT errors when I upgraded prime95 to V21. =20 At the same time, I saw that the processor temperature went up from = 45=B0 to 50=B0 Celsius.=20 To fix the problem, I had to reduce the overclocking and I lost 25% of = speed improvements... =20 Regards, Jean-Yves=20 - -----Original Message----- From: David Jaggard [mailto:david.jaggard@ttpcom.com] Sent: 12 September 2001 16:45 To: mersenne@base.com Subject: Mersenne: Torture test passes but normal use fails! Dear Mailing List, =20 Could somebody give me some advice? =20 I have an overclocked AMD Duron machine using windows 98SE running at = just under 1GHz and have been running prime95 v20 successfully for many = months. I have occasionally had hardware errors when I have tried to overclock = further but at the current speed prime95 v20 is happy. =20 Yesterday (11-09-2001) I upgraded prime95 from v20 to v21. My tests = ressumed only to quickly fail with a SUMOUT/possible hardware failure. I made = some small changes to speed and core voltage but could not correct the = errors. I decided to run the torture test and I left it running all night. This morning I viewed results.txt and all tests had passed yet the normal operation of the program still fails. Surely if my system was unstable = the torture test should fail! Is it possible that in the new release the = normal primality tests are more stressful than the torture test? Or is there a = bug? =20 On a seperate matter why is there no processor catagory for AMD Duron = chips and yet there is a catagory for Intel Celerons? I'm proud of the fact = that my budget setup is faster than some ready-made Athlon 1GHz systems! =20 Thanks in advance for any feedback =20 Davy - ------_=_NextPart_001_01C13BA4.6547BC80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I had=20 the same problem on my overclocked Athlon that started to = produce=20 SUMOUT errors when I upgraded prime95 to=20 V21.  
At the=20 same time, I saw that the processor temperature went up from 45=B0 to = 50=B0=20 Celsius. 
To fix=20 the problem, I had to reduce the overclocking and I lost 25% = of speed=20 improvements...
 
Regards, Jean-Yves 
-----Original Message-----
From: David Jaggard=20 [mailto:david.jaggard@ttpcom.com]
Sent: 12 September 2001=20 16:45
To: mersenne@base.com
Subject: Mersenne: = Torture test=20 passes but normal use fails!

Dear Mailing List,
 
Could somebody give me some = advice?
 
I have an overclocked AMD Duron = machine using=20 windows 98SE running at just under 1GHz and have been running prime95 = v20=20 successfully for many months. I have occasionally had hardware errors = when I=20 have tried to overclock further but at the current speed prime95 v20 is = happy.
 
Yesterday (11-09-2001) I upgraded = prime95 from v20=20 to v21. My tests ressumed only to quickly fail with a SUMOUT/possible = hardware=20 failure. I made some small changes to speed and core voltage but could = not=20 correct the errors. I decided to run the torture test and I left it = running all=20 night. This morning I viewed results.txt and all tests had passed yet = the normal=20 operation of the program still fails. Surely if my system was unstable = the=20 torture test should fail! Is it possible that in the new release the = normal=20 primality tests are more stressful than the torture test? Or is there a = bug?
 
On a seperate matter why is there no = processor=20 catagory for AMD Duron chips and yet there is a catagory for Intel = Celerons? I'm=20 proud of the fact that my budget setup is faster than some ready-made = Athlon=20 1GHz systems!
 
Thanks in advance for any = feedback
 
Davy
- ------_=_NextPart_001_01C13BA4.6547BC80-- - --------------InterScan_NT_MIME_Boundary-- _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 12 Sep 2001 10:00:41 -0700 From: "Aaron Blosser" Subject: Re: Mersenne: Torture test passes but normal use fails! This is a multi-part message in MIME format. - ------=_NextPart_000_016A_01C13B71.C80E2D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maybe it's a case of the new version working *too* good. The = improvements to the code, like the prefetch, is doing such a good job of = keeping the FPU busy that it heats up more and causes problems if you've = overclocked. That'd be interesting, if true. Meanwhile, I hope and pray that any New York or DC (and other area) = GIMPSers are okay. Aaron ----- Original Message -----=20 From: Canart Jean-Yves=20 To: 'mersenne@base.com'=20 Sent: Wednesday, September 12, 2001 9:03 AM Subject: FW: Mersenne: Torture test passes but normal use fails! I had the same problem on my overclocked Athlon that started to = produce SUMOUT errors when I upgraded prime95 to V21. =20 At the same time, I saw that the processor temperature went up from = 45=B0 to 50=B0 Celsius.=20 To fix the problem, I had to reduce the overclocking and I lost 25% of = speed improvements... Regards, Jean-Yves - ------=_NextPart_000_016A_01C13B71.C80E2D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maybe it's a case of the new version = working *too*=20 good.  The improvements to the code, like the prefetch, is doing = such a=20 good job of keeping the FPU busy that it heats up more and causes = problems if=20 you've overclocked.
 
That'd be interesting, if = true.
 
Meanwhile, I hope and pray that any New = York or DC=20 (and other area) GIMPSers are okay.
 
Aaron
----- Original Message -----
From:=20 Canart Jean-Yves
Sent: Wednesday, September 12, = 2001 9:03=20 AM
Subject: FW: Mersenne: Torture = test=20 passes but normal use fails!

I=20 had the same problem on my overclocked Athlon that started = to=20 produce SUMOUT errors when I upgraded prime95 to=20 V21.  
At=20 the same time, I saw that the processor temperature went up from 45=B0 = to 50=B0=20 Celsius. 
To=20 fix the problem, I had to reduce the overclocking and I lost = 25% of=20 speed improvements...
 
Regards, = Jean-Yves
- ------=_NextPart_000_016A_01C13B71.C80E2D00-- _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 12 Sep 2001 20:00:37 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: Mersenne: Torture test passes but normal use fails! On 12 Sep 2001, at 15:44, David Jaggard wrote: > I have an overclocked AMD Duron machine using windows 98SE running at > just under 1GHz and have been running prime95 v20 successfully for > many months. I have occasionally had hardware errors when I have tried > to overclock further but at the current speed prime95 v20 is happy. > > Yesterday (11-09-2001) I upgraded prime95 from v20 to v21. My tests > ressumed only to quickly fail with a SUMOUT/possible hardware failure. > I made some small changes to speed and core voltage but could not > correct the errors. I decided to run the torture test and I left it > running all night. This morning I viewed results.txt and all tests had > passed yet the normal operation of the program still fails. SUMOUT is often (not invariably, but often) caused by dodgy software. Sound card drivers for Windows 9x/ME are the most likely culprits. If this is the cause then the Good News is that your results are most likely OK. Note that a sound card driver problem _could_ be sensitive to Prime95 version as the driver could be bombing memory contents which are effectively unused in v20 but contain active data or code in v21. This might also explain why the torture test fails to reveal the problem - obviously there are _some_ minor differences between the code executed during torture testing and that used for production LL/DC testing. > Surely if > my system was unstable the torture test should fail! Is it possible > that in the new release the normal primality tests are more stressful > than the torture test? Or is there a bug? Umm. Not sure about that. The torture test does not (cannot!) test every combination of operand values which can occur in "real" data. Anyway if it's a driver problem then maybe it runs OK overnight because the device with the duff driver isn't being used. If the sumouts occur at the same iteration number then you _could_ have found a bug caused by either a program error or a design flaw in the processor which occurs with very specific data. If they occur at random then it sounds much more like interference from a bad device driver or some other hardware problem - maybe overheating. Did you try re-rerunning the specific selftest for the FFT runlength used by the exponent you're having a problem with? (The FFT runlength is the nearest "round" number to the size of the Pnnnnnnn savefile divided by 4096. To force a re-run, stop Prime95, edit local.ini removing the appropriate SelfTestNNNN=1 line & restart Prime95.) If that works but the actual assignment keeps failing, it _might_ be a problem caused by specific data values. One way to _prove_ this would be to take the savefile to a different system & run it on that - if it's a data value problem that will fail too. Next try on a system with an Intel processor - if that fails it's a program problem, otherwise the CPU is doing something strange. I have a variety of reasonably reliable systems with different CPU types available if that's of any help. If you suspect that it might be a driver problem, try upgrading the sound card driver (it's usually the sound card, or integrated Winmodem if you have one of those), next unloading the sound card driver, next physically removing the sound card. If it's a Winmodem problem then the system should be reliable so long as the modem lead is unplugged. In the event you find a driver problem is to blame, your options are (a) put up with it, (b) replace the driver, (c) replace the hardware for a unit with a "known safe" driver or (d) change your OS to Win NT/2000/XP, or linux, which will not suffer this sort of driver problem since they use properly partitioned memory. To rule out overheating on your own system, I suggest you try: (a) making sure that the cooling fan(s) in the case and/or power supply are working - on AMD Athlon/Duron systems you don't actually need to check the processor fan; the processor will die of extreme overheating in seconds if that fails! If your mainboard has a chipset cooling fan, check that is running, too. (b) blowing any accumulated crud (compacted dust) out of the processor heatsink and away from the large chipsets on the mainboard and the memory; (c) reducing the processor to its rated speed. If this clears the problem then I'm afraid you're maybe going to have to live with it. BTW processors are designed for 4 to 7 years reliable operation at their rated speed. They will age more quickly when overclocked, mostly because of the higher temperatures generated by faster switching, and especially if the core voltage is increased. As the processor ages it will become increasingly less able to run reliably at clock speeds in excess of its rating. Critical components on the mainboard, in particular the voltage regulator, age too. Some mainboards are known to have problems with capacitors used by the CPU voltage reg which are located close to the CPU socket; consequently they tend to run quite warm due to being in the exhaust air flow from the CPU cooler. If those caps start to go bad then the first thing that will happen is that the CPU core voltage will become unstable, and so will the CPU - irrespective of the CPU clock speed, though higher clock speeds tend to rely on closer control of the core voltage, as well as making the CPU voltage reg's job harder by drawing more current. > > On a seperate matter why is there no processor catagory for AMD Duron > chips and yet there is a catagory for Intel Celerons? I'm proud of the > fact that my budget setup is faster than some ready-made Athlon 1GHz > systems! Um. There is no technical reason for any difference in coding between Duron & Thunderbird. Although it was never implemented, and would be a waste of effort now, the early Celeron 266 and 300 CPUs have _no_ L2 cache and could perhaps have benefited from slightly revised code. But I guess the real reason is that no-one told George how to tell the difference between Duron, Thunderbird and the original Athlon with 512K L2 cache running "slowly" from the processor ID values returned. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 12 Sep 2001 22:53:43 +0200 From: "Steinar H. Gunderson" Subject: Mersenne: Re: Torture test passes but normal use fails! [snipped: text explaining possible cause of prime95 errors] Whoa, That's quite a comprehensive text you have there, Brian. What if one put something like this online somewhere on mersenne.org? /* Steinar */ - - who just got his motherboard replaced AGAIN... same error as last time (random reboots more and more often, and finally motherboard death) - -- Homepage: http://www.sesse.net/ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 13 Sep 2001 09:52:12 +0100 From: "David Jaggard" Subject: Re: Mersenne: Torture test passes but normal use fails! Brian, Thankyou for the help. However I wrote the email to the mailing list at work and what I reported to be a SUMOUT was actually a SUMINP != SUMOUT error. I realize these are two different types of errors and that the actual error I see is not going to be caused by driver failure. If I have time tonight I will try to run the torture test at the same FFT as the LL test. I'm not going to complain if I have to reduce the processor speed a bit because I've obviously gone a bit too far for my particular chip. A chip is only as fast as its reliability afterall! My only concern is that the torture test should be a more accurate measure of hardware stability than the LL test and my intial findings suggest that perhaps it isn't. With the addition of the option at startup to only run stress tests (added specifically for overclockers I believe) the torture test needs to be the more accurate test as many uses may never run the LL tests. On the Athlon/Duron ID front, if its not possible to detect the chip could we not have an option to set it manually? I'd just like things to look right in the stats. Thanks again Davy - ----- Original Message ----- From: To: David Jaggard Cc: Sent: Wednesday, September 12, 2001 9:00 PM Subject: Re: Mersenne: Torture test passes but normal use fails! > On 12 Sep 2001, at 15:44, David Jaggard wrote: > > > I have an overclocked AMD Duron machine using windows 98SE running at > > just under 1GHz and have been running prime95 v20 successfully for > > many months. I have occasionally had hardware errors when I have tried > > to overclock further but at the current speed prime95 v20 is happy. > > > > Yesterday (11-09-2001) I upgraded prime95 from v20 to v21. My tests > > ressumed only to quickly fail with a SUMOUT/possible hardware failure. > > I made some small changes to speed and core voltage but could not > > correct the errors. I decided to run the torture test and I left it > > running all night. This morning I viewed results.txt and all tests had > > passed yet the normal operation of the program still fails. > > SUMOUT is often (not invariably, but often) caused by dodgy > software. Sound card drivers for Windows 9x/ME are the most > likely culprits. If this is the cause then the Good News is that your > results are most likely OK. Note that a sound card driver problem > _could_ be sensitive to Prime95 version as the driver could be > bombing memory contents which are effectively unused in v20 but > contain active data or code in v21. This might also explain why the > torture test fails to reveal the problem - obviously there are _some_ > minor differences between the code executed during torture testing > and that used for production LL/DC testing. > > > Surely if > > my system was unstable the torture test should fail! Is it possible > > that in the new release the normal primality tests are more stressful > > than the torture test? Or is there a bug? > > Umm. Not sure about that. The torture test does not (cannot!) test > every combination of operand values which can occur in "real" data. > > Anyway if it's a driver problem then maybe it runs OK overnight > because the device with the duff driver isn't being used. > > If the sumouts occur at the same iteration number then you > _could_ have found a bug caused by either a program error or a > design flaw in the processor which occurs with very specific data. If > they occur at random then it sounds much more like interference > from a bad device driver or some other hardware problem - maybe > overheating. > > Did you try re-rerunning the specific selftest for the FFT runlength > used by the exponent you're having a problem with? (The FFT > runlength is the nearest "round" number to the size of the > Pnnnnnnn savefile divided by 4096. To force a re-run, stop Prime95, > edit local.ini removing the appropriate SelfTestNNNN=1 line & > restart Prime95.) > > If that works but the actual assignment keeps failing, it _might_ be > a problem caused by specific data values. One way to _prove_ this > would be to take the savefile to a different system & run it on that - > if it's a data value problem that will fail too. Next try on a system > with an Intel processor - if that fails it's a program problem, > otherwise the CPU is doing something strange. I have a variety of > reasonably reliable systems with different CPU types available if > that's of any help. > > If you suspect that it might be a driver problem, try upgrading the > sound card driver (it's usually the sound card, or integrated > Winmodem if you have one of those), next unloading the sound > card driver, next physically removing the sound card. If it's a > Winmodem problem then the system should be reliable so long as > the modem lead is unplugged. In the event you find a driver problem > is to blame, your options are (a) put up with it, (b) replace the > driver, (c) replace the hardware for a unit with a "known safe" driver > or (d) change your OS to Win NT/2000/XP, or linux, which will not > suffer this sort of driver problem since they use properly partitioned > memory. > > To rule out overheating on your own system, I suggest you try: > > (a) making sure that the cooling fan(s) in the case and/or power > supply are working - on AMD Athlon/Duron systems you don't > actually need to check the processor fan; the processor will die of > extreme overheating in seconds if that fails! > > If your mainboard has a chipset cooling fan, check that is running, > too. > > (b) blowing any accumulated crud (compacted dust) out of the > processor heatsink and away from the large chipsets on the > mainboard and the memory; > > (c) reducing the processor to its rated speed. If this clears the > problem then I'm afraid you're maybe going to have to live with it. > > BTW processors are designed for 4 to 7 years reliable operation at > their rated speed. They will age more quickly when overclocked, > mostly because of the higher temperatures generated by faster > switching, and especially if the core voltage is increased. As the > processor ages it will become increasingly less able to run reliably > at clock speeds in excess of its rating. > > Critical components on the mainboard, in particular the voltage > regulator, age too. Some mainboards are known to have problems > with capacitors used by the CPU voltage reg which are located > close to the CPU socket; consequently they tend to run quite > warm due to being in the exhaust air flow from the CPU cooler. If > those caps start to go bad then the first thing that will happen is > that the CPU core voltage will become unstable, and so will the > CPU - irrespective of the CPU clock speed, though higher clock > speeds tend to rely on closer control of the core voltage, as well as > making the CPU voltage reg's job harder by drawing more current. > > > > On a seperate matter why is there no processor catagory for AMD Duron > > chips and yet there is a catagory for Intel Celerons? I'm proud of the > > fact that my budget setup is faster than some ready-made Athlon 1GHz > > systems! > > Um. There is no technical reason for any difference in coding > between Duron & Thunderbird. Although it was never implemented, > and would be a waste of effort now, the early Celeron 266 and 300 > CPUs have _no_ L2 cache and could perhaps have benefited from > slightly revised code. But I guess the real reason is that no-one > told George how to tell the difference between Duron, Thunderbird > and the original Athlon with 512K L2 cache running "slowly" from > the processor ID values returned. > > > Regards > Brian Beesley > _________________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _________________________________________________________________________ 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 #883 ******************************