Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Feb 1998 12:26:30 -0100 (GMT)
From:      Remy NONNENMACHER <remy@synx.com>
To:        Atipa <freebsd@atipa.com>
Cc:        "John S. Dyson" <dyson@FreeBSD.ORG>, adoane@eagle.ais.net, freebsd-smp@FreeBSD.ORG
Subject:   Re: Dual proc PII MB of choice?
Message-ID:  <Pine.A32.3.91.980225120956.2188G-100000@rs1>
In-Reply-To: <Pine.BSF.3.91.980224191024.7663B-100000@dot.ishiboo.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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).
 
> Kevin
> 
> On Tue, 24 Feb 1998, John S. Dyson wrote:
> 
> > Atipa said:
> > > 
> > > 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. 
> > > 
> > Are you sure?  It is probably that many of those who feel that
> > they must overclock are running lmbench and dhrystone all day.
> > Indeed, overclocking often improves lmbench performance significantly,
> > and the amount of work done with that additional lmbench performance
> > means that even more pages of performance reports can be output
> > each day!!! :-).
> > 

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. The idle state of a Unix machine 
is very helpfull. 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. (Note that M$ stuff, by itself, is not 
stable enought to be a pertinent tool).


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.A32.3.91.980225120956.2188G-100000>