Date: Wed, 25 Feb 1998 09:48:36 -0700 (MST) From: Atipa <freebsd@atipa.com> To: Remy NONNENMACHER <remy@synx.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Dual proc PII MB of choice? Message-ID: <Pine.BSF.3.91.980225092250.13832C-100000@dot.ishiboo.com> In-Reply-To: <Pine.A32.3.91.980225120956.2188G-100000@rs1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Feb 1998, Remy NONNENMACHER wrote: > > On Tue, 24 Feb 1998, Atipa wrote: > > > > > If you could overclock a hard drive I'd have to agree.. :) > > (... Lets see how this Cheetah does at 15,000 RPM... ) > > > > use ccd. i got more than 50MB/s using 4 disks and 34MB/s with 2 (IBM DGVS > 9GB - 10050 RPM). Cool! > > > > Our failure rates on CPUs have jumped by an order of magnitude since > > > > people have started oc'ing. Overclocking voids most distributors > > > > warranties, and is not worth the risk. The CPU is hardly ever the > > > > bottleneck anyway. > > The big problem seems to be the heating. AMD and Cyrix procs goes very > high. For exemple, running the RC5 client on an AMD make the temp goes to > hell in only 2 minutes. On the other hand, i Oc'd a PII 300 to 337Mh and > seen no noticeable temperature change. You are correct that heating is the _primary_ enemy, but it does not change the realilty that operating processors outside of their specification increases the chance of electron migration and error, and should not be condoned. > The idle state of a Unix machine is very helpfull. In other words, oc'ing usually won't make your system noticably faster. :) > All Unix running procs, here, are cold and same procs > running M$ stuffs are very hot. (At the point we got problems with Cyrix > procs at native frequencies). I would recommand that an Overclocking > operation will be followed by a week of loading, testing, etc... And that > returning to normal operation would be done in case of any, even little, > incident that can't be explained. What about the long term effect on the processors? There is a good chance you are shortening the longevity of the processor, even if it does not initially produce errors. > (Note that M$ stuff, by itself, is not > stable enought to be a pertinent tool). That is precisely why I don't recommend overclocking; there are so mary variables to deal with that adding one more big one is a big pain in the ass. I agree that _most_ the time oc'ed processors do their job, but it may take several hours to resolve such intermittancies. OC'ing problems are horribly unpredictable. Do you honestly notice enough of a performance gain to justify the potential headaches and expenses? I _had_ been an overclocker, but have realized it just ain't worth it :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.980225092250.13832C-100000>