Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!sharkey!clmqt!strike
From: strike@clmqt.marquette.Mi.US (Tim Bowser)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: 16mhz 386sx running at 20mhz
Message-ID: <1990Aug11.140948.24462@clmqt.marquette.Mi.US>
Date: 11 Aug 90 14:09:48 GMT
References: <1990Aug7.230306.16069@agate.berkeley.edu> <1990Aug9.144532.677@athena.mit.edu> <12743@june.cs.washington.edu> <32458@eerie.acsu.Buffalo.EDU>
Organization: Enterprise Information System
Lines: 30

jones@acsu.buffalo.edu (terry a jones) writes:

>Rob is correct..  Manufacturers will sort CPU chips by speed as they pass 
>testing at that speed.  I have had good luck running a number of CPUs at
>elevated clock rates.  There is no justification to the theory that the
>CPU chip will "wear out" running at an elevated clock rate.  I would be
>concerned that increased temperature would cause the CPU to be more prone
>to intermittent failure, since it is running beyond guaranteed speeds.
>Personally, I'd get the box warm, set some diagnostics running, and let it
>fly for a few days.  If there was no flakiness, keep it, being happy with
>the deal I got...otherwise send it back an complain.

This is *precisely* what I have here, in a Pioneer 386sx 20mHz motherboard.
The CPU is stamped 16mHz, but the manufacturer of the board stressed the
chip at 20 with no failure.  The distributor of the motherboard claims to
do the same thing, and from six months of continuous operations in the
Xenix environment, I have zero complaints.

Because it is running at above the stamped spec, I take pains to make sure
the system receives as much cooling air as it can get.  Heck, this is good
advice for *any* system, no matter what the internals are doing.

Keep the machine.


-- 
 Tim Bowser  ("Strikemaster")  |  Standard  |  mailrus!sharkey!clmqt!strike
Enterprise Information System  | Disclaimer |  strike@clmqt.marquette.Mi.US
      Marquette, Mi. USA       |    Here    |     Voice:(906)-346-6735
=> UNIX: The Adventure Begins... To vi, or not to vi, that is the question. <=