🚀 go-pugleaf

On Tue, 16 Nov 1999 10:24:32 GMT, Michael Bungey <spam@fuelwise.clara.co.uk>
wrote:

>>
>The problem is adequate cooling I should think... that's the only reason
>it'd crash overclocked but not normally clocked =>  Buy a better
>heatsink/fan =)

Overheating is a separate problem.  It can be a consequence of overclocking,
and overheating can cause errors, but that's not the only reason why an
overclocked device goes wrong. If the logic can't respond fast enough to
have the right data at the output when the next clock pulse arrives, there
will be errors, simply because the internal logic can't move fast enough (at
any temperature).

-- 
Anahata
anahata@freereed.demon.co.uk  -+- http://www.freereed.demon.co.uk
020 7229 6076 (H)     0976 263827 (M)    020 7598 0208 (F)
======= brought to you from a Debian 2.1 GNU/Linux system =======

On Tue, 16 Nov 1999 at 23:26:07, Anahata <anahata@freereed.demon.co.uk>
wrote in demon.tech.pc:
(Reference: <f6ps08.c43.ln@stravinsky>)

>On Tue, 16 Nov 1999 10:24:32 GMT, Michael Bungey <spam@fuelwise.clara.co.uk>
>wrote:
>
>>>
>>The problem is adequate cooling I should think... that's the only reason
>>it'd crash overclocked but not normally clocked =>  Buy a better
>>heatsink/fan =)
>
>Overheating is a separate problem.  It can be a consequence of overclocking,
>and overheating can cause errors, but that's not the only reason why an
>overclocked device goes wrong. If the logic can't respond fast enough to
>have the right data at the output when the next clock pulse arrives, there
>will be errors, simply because the internal logic can't move fast enough (at
>any temperature).
>
Well said. I was wondering when someone would try and make this point.
Overclocking might work with some components, possibly even the majority
of components. You are only guaranteed that the component you have
bought will work at the speed it is claimed to.

If you overclock, How do you know that everything will work all the
time, in all circumstances, and what certainty do you have that there
will be an error reported if anything fails to work.

Personally, although mine is a personal home system, for which I pay, I
place more reliance on my data and the results of its processing to rely
on luck in that manner. That is not, of course, a criticism of any who
do overclock, just a cautionary note to them if things go wrong - my
sympathy will not be that obvious.

-- 
John Underwood

Is usb still unsupported in linux??


-- 
Oz

In article <MWhAYGAhnfM4EwpP@jsunderwood.demon.co.uk>, John Underwood
<john@jsunderwood.demon.co.uk> writes

>Well said. I was wondering when someone would try and make this point.
>Overclocking might work with some components, possibly even the majority
>of components. You are only guaranteed that the component you have
>bought will work at the speed it is claimed to.

And probably not even then in truth.
They many or may not agree to exchange what you may consider faulty
goods that do not meet the spec. I know of no firms that will offer a
pledge that all their millions of products are perfect and will always
stay that way.

So how do you check the system you are using is working properly?
You test it from time to time.
You do the same for overclocked systems.
After all components drift with time and sometimes some drift such that
the item no longer works reliably, guarantee or no, overclocked or no.

>If you overclock, How do you know that everything will work all the
>time, in all circumstances, 

Even if you don't, how do you KNOW this?
You don't. Mostly because things don't always work all the time and in
all circumstances whether guaranteed or not.

>and what certainty do you have that there
>will be an error reported if anything fails to work.

The same certainty you have with any product.

Your argument is specious in the face of the overwhelming evidence of
experience some of which has been posted to this thread.

-- 
Oz

In article <80m04m$cen$1@reef.news.technocom.net>, Philip Bragg
<philb@vossnet.co.uk> writes
>A few weeks ago I bought a non-bootable �25 inc vat "Iwill 2903" which is
>basically an Advansys ABP-940 without the boot ROM and the settings storage
>EEPROM on board. I'm fairly good with a soldering iron, so I soldered a DIL
>socket into the vacant space on the board which looked as though it should
>have the boot ROM on it, then I used my Black and Decker paint stripping
>heat gun to remove the EEPROM from an old 3com ethernet card (most NICs have
>EEPROMs on them,

Do you mean as in bootable eeproms? I wish you'd show me where I'm after
one of those (actually for a 3com card) I've always looked at computer
fairs etc, I've *never* seen *one*.

>The end result is I have a bootable Ultra (narrow) SCSI card which cost me
>�25, about 3/4 of an hour of my time, a knackered ethernet card, old 386
>BIOS chip and some solder. It occasionally fails to reset which is fine by
>me as I'm only using it in a test bed machine, I wouldn't want to put a hack
>like this in a server anyway.

(OZ eat your heart out! <g>)
-- 
John Chapple

In article <f6ps08.c43.ln@stravinsky>, anahata@freereed.demon.co.uk wrote:
|> Overheating is a separate problem.  It can be a consequence of overclocking,
|> and overheating can cause errors, but that's not the only reason why an
|> overclocked device goes wrong. If the logic can't respond fast enough to
|> have the right data at the output when the next clock pulse arrives, there
|> will be errors, simply because the internal logic can't move fast enough (at
|> any temperature).

Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
hotter it is, the slower it runs.  Extra cooling in overclocked machines has two
functions:
 o Stop the device from exceeding a safe temperature limit, beyond which the chip
   can be physically damaged
 o Keep the device as cool as possible, to maximise the speed at which it can run
   The colder a device is, the faster it will run.

A device which will only run at it's rated speed with normal cooling will be able 
to run faster if you can keep it cooler.  This is the reason why the Cool Athlon 
machines can run at such ridiculously high clock speeds, because they have a
built-in refrigeration unit to keep the CPU very cold.



-- 
David Smith, Silicon Design Engineer  Tel: +44 (0)1454 462380 (direct)
STMicroelectronics                    Fax: +44 (0)1454 617910
1000 Aztec West            TINA (ST only): (065) 2380
Almondsbury                          Home: 01454 616963
BRISTOL                            Mobile: 07932 642724
BS32 4SQ                       Work Email: dsmith@bristol.nospam.st.com
                               Home Email: David.Smith@gazpacho.nospam.demon.co.uk

Oz <Oz@upthorpe.demon.co.uk> doodled in uk.comp.os.linux:

> Is usb still unsupported in linux??

You tell me. Why not check out <http://www.linuxvoodoo.org/howto/usb/usb.htm>
and <http://www.linux-usb.org> first though?

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

In article <slrn8353d1.3ei.piglet@pigsty.td.micromuse.co.uk>, Tim Haynes
<piglet@glutinous.custard.org> writes
>Oz <Oz@upthorpe.demon.co.uk> doodled in uk.comp.os.linux:
>
>> Is usb still unsupported in linux??
>
>You tell me. Why not check out <http://www.linuxvoodoo.org/howto/usb/usb.htm>
>and <http://www.linux-usb.org> first though?

I guess that's a long way of saying that it is now supported?

-- 
Oz

dsmith@bristol.nospam.st.com (Dave Smith) writes:

> Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
> hotter it is, the slower it runs.  Extra cooling in overclocked machines has two
> functions:
>  o Stop the device from exceeding a safe temperature limit, beyond which the chip
>    can be physically damaged
>  o Keep the device as cool as possible, to maximise the speed at which it can run
>    The colder a device is, the faster it will run.
> 

I'm just back from the pub so restraint mode=unrestrained

Bollocks, the phrase "Device Speed is always a function of
temperature" is wrong. "temperature is a function of device speed" is
correct. CMOS only uses current ( generates heat ) when it switches,
the faster you switch a CMOS circuit the hotter it gets.

The phrase "Stop the device from exceeding a safe temperature limit,
beyond which the chip" is correct.

The phrase "Keep the device as cool as possible, to maximise the speed
at which it can run. The colder a device is, the faster it will run."
is patently untrue. Keeping the temperature will stop the chance of
breakdown by stopping failures due to thermal problems however it will
not stop electrical limits ( capacitance etc. ). If we could cool the
systems enough to make them run fast enough we would be using ZX-81s
in liquid nitrogen clocking at 1GHz. Now there is a thought!

Regards

Robin

In article <80ttgr$1aq2@gamma.dmz-eu.st.com>, Dave Smith
<dsmith@bristol.nospam.st.com> writes

>In article <f6ps08.c43.ln@stravinsky>, anahata@freereed.demon.co.uk wrote:
>|> Overheating is a separate problem.  It can be a consequence of overclocking,
>|> and overheating can cause errors, but that's not the only reason why an
>|> overclocked device goes wrong. If the logic can't respond fast enough to
>|> have the right data at the output when the next clock pulse arrives, there
>|> will be errors, simply because the internal logic can't move fast enough (at
>|> any temperature).
>
>Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
>hotter it is, the slower it runs.  

Garbage. You have your cause and effect mixed up.
Actually IIRC conventional silicon semiconductors run slightly FASTER
when hot because of a *small* increase in electron/hole speed.

>Extra cooling in overclocked machines has two
>functions:
> o Stop the device from exceeding a safe temperature limit, beyond which the 
>chip
>   can be physically damaged

Correct.

> o Keep the device as cool as possible, to maximise the speed at which it can 
>run
>   The colder a device is, the faster it will run.

Crap.

>A device which will only run at it's rated speed with normal cooling will be 
>able 
>to run faster if you can keep it cooler.  

Correct. As has been said above the faster it runs (assuming the chip
fabrication actually permits this, ie switching speeds and internal
delays permitting) the more heat it GENERATES so to dissipate the heat a
colder chip SURFACE temperature is required to prevent meltdown/devices-
going-out-of-spec. Please note and understand heat diffusion and
temperature between ambient and junction. If you don't understand this
then you don't have a clue what's going on and would be well advised to
shut up.

>This is the reason why the Cool Athlon 
>machines can run at such ridiculously high clock speeds, because they have a
>built-in refrigeration unit to keep the CPU very cold.

No, it's to maintain the chip junctions within their thermal limit and
STILL dissipate the greater heat produced by the elevated switching
speed.

-- 
Oz

In article <80ttgr$1aq2@gamma.dmz-eu.st.com>, Dave Smith
<dsmith@bristol.nospam.st.com> writes
>In article <f6ps08.c43.ln@stravinsky>, anahata@freereed.demon.co.uk wrote:
>|> Overheating is a separate problem.  It can be a consequence of overclocking,
>|> and overheating can cause errors, but that's not the only reason why an
>|> overclocked device goes wrong. If the logic can't respond fast enough to
>|> have the right data at the output when the next clock pulse arrives, there
>|> will be errors, simply because the internal logic can't move fast enough (at
>|> any temperature).
>
>Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
>hotter it is, the slower it runs.  Extra cooling in overclocked machines has two
>functions:
> o Stop the device from exceeding a safe temperature limit, beyond which the 
>chip
>   can be physically damaged
> o Keep the device as cool as possible, to maximise the speed at which it can 
>run
>   The colder a device is, the faster it will run.
>
>A device which will only run at it's rated speed with normal cooling will be 
>able 
>to run faster if you can keep it cooler.  This is the reason why the Cool Athlon 
>machines can run at such ridiculously high clock speeds, because they have a
>built-in refrigeration unit to keep the CPU very cold.
>
>
You don't appear to have taken anything other than higher clock speed =
higher power dissipation into account. There are a few other reasons a
device has a clock limit, parasitic capacitance for example...
-- 
|Gav|

ICQ# 19875282
gavin@provocative.freeserve.co.uk

On Wed, 17 Nov 1999 07:28:33 +0000, Oz <Oz@upthorpe.demon.co.uk> wrote:

>>If you overclock, How do you know that everything will work all the
>>time, in all circumstances, 
>
>Even if you don't, how do you KNOW this?
>You don't. Mostly because things don't always work all the time and in
>all circumstances whether guaranteed or not.

It's not quite as vague as that.  Semiconductor devices are specified to
work over a specified range of temperatures, supply voltages and, at the
external interfaces, limits of logic voltage levels and output currents. The
way in which the performance varies with these parameters is often quite
systematic and well known, so it is easy to define a few worst case
combinations of conditions, under which if a chip passes its tests you can
be confident that it will work uder all other combinations which are inside
the "recommended operating limits".  While these conditions are met, the
manufacturer can guarantee correct operation.  Note that "guarantee" is not
scientific proof that it will work; it indicates that the supplier can
afford to offer you your money back if it doesn't, because any remaining
failures will be rare cases of premature ageing due to random flaws in the
silicon, i.e. a quite different mechanism.

I was once told that Texas sorted their TTL devices into mil spec and
commercial spec by performing a single leakage current test, which
characterised the chip.  If that was within certain limits and the chip had
already passed a simple functionality test under normal conditions, they
knew the chip would work over the -55 to +125 degree temperature range and
4.5 to 5.5 Volts supply.  Within wider limits it would be OK fo 0 to +70 and
4.75 to 5.25 volts.

>Your argument is specious in the face of the overwhelming evidence of
>experience some of which has been posted to this thread.

That's unneccesarily strong.  There are systematic limits to the operating
conditions, and a chip as supplied and run at the correct clock speed and
other conditions is very likely to be reliable.

For any chip there will be a clock speed over which the error rate increases
dramatically.  That speed will of course be above the rated clock speed, and
(as discussed earlier) may sometimes be above the next standard step up in
clock speed too, if you are lucky.

In other words, at a given clock speed a given chip will either work or it
won't.  Of course that's not the only hardware reason why a PC may crash,
but that's another matter.

-- 
Anahata
anahata@freereed.demon.co.uk  -+- http://www.freereed.demon.co.uk
020 7229 6076 (H)     0976 263827 (M)    020 7598 0208 (F)
======= brought to you from a Debian 2.1 GNU/Linux system =======

On Wed, 17 Nov 1999 at 13:55:13, Anahata <anahata@freereed.demon.co.uk>
wrote in demon.tech.pc:
(Reference: <14cu08.g51.ln@127.0.0.1>)

>In other words, at a given clock speed a given chip will either work or it
>won't.  Of course that's not the only hardware reason why a PC may crash,
>but that's another matter.

Would you always know if it had failed to work correctly. For example,
if overclocking meant that there wasn't enough time for carry bits to
ripple their way through a register. There are probably other examples.
Why would an error be reported when, if everything is done according to
spec, there can be no error. Occasionally losing the carry into the most
significant bit of a value may not make much difference in a game -
perhaps it might add a little extra excitement. I wouldn't want to
discover that it had happened on unknown occasions in my accounts.

In broad terms, there are four things that can happen to a transaction -
it can work perfectly, it can crash the computer, it fails and generates
an error message telling you that it has failed, and it goes wrong and
doesn't tell you.

I can put up with the first three. I will always do my utmost to reduce
the risk of the last happening.
-- 
John Underwood

In article <slrn8386n3.e4.piglet@pigsty.td.micromuse.co.uk>, Tim Haynes
<piglet@glutinous.custard.org> writes

>Yup, I'd admit to being relatively pedantic, but *how* does one determine
>whether it's speed that affects temperature *or* the other way round, in a
>given case? (Other than, say, it being you wiggling the thermostat, sort of
>thing!)

Very simple. See how fast you can run an 8MHz 8086 as you decrease the
temperature. You will find there is a maximum rate and that this is very
little affected by temperature simply because the switching speed of the
components limits the maximum clock speed. This is an n-mos chip (ie NOT
cmos) so the dissipation does not tend to zero as the clockspeed tends
to zero. You might like to try an early cmos processor (some 486's IIRC,
and notebook 386's) and compare dissipation (ie current consumption) vs
clock speed where you will find that dissipation is approximately
proportional to clockspeed. In this case it will be very clear that it's
clock speed that *causes* temperature elevation and not temperature that
permits higher clockspeeds.

Really it's only been recent chips that have dissipated enough for the
package dissipation to be a limiting factor in the permittable maximum
clockspeed. Hence the use of lower core voltages in an effort to
restrict dissipation at any given clockspeed (because dissipation is
roughly proportional to supply voltage).

-- 
Oz

In article <3833dc8c.0@nnrp1.news.uk.psi.net>, Andy Repton <andy+news@DE
LETE.pteron.demon.co.ME.uk> writes

>I suggest you look at the address Dave writes from. ST is a 
>semiconductor manufacturer. I am a semiconductor designer and
>fully agree with Dave.

Nope, he is wrong. You should know better.

Firstly the junction temperature of a normal spec chip with normal
cooling is probably about 100C or thereabouts. The junction temperature
of a clocked up chip which of course dissipates much more but with a
supercooling of the chip will STILL be about 100C or thereabouts. If not
and the process permits higher speed then clock it some more.

Your logic is thus totally faulty because the active region of the chip
is at the same temperature either way.

I could go on but I sincerely hope you don't design chips as you show
such profound ignorance of how they behave in a system.

You really should learn about junction to ambient heatflows then you
could understand what I am talking about. 

-- 
Oz

Oz <Oz@upthorpe.demon.co.uk> doodled in uk.comp.os.linux:

> Your logic is thus totally faulty because the active region of the chip
> is at the same temperature either way.
> I could go on but I sincerely hope you don't design chips as you show
> such profound ignorance of how they behave in a system.
> You really should learn about junction to ambient heatflows then you
> could understand what I am talking about. 

Come, come, gentlemen (and any ladies who happen to be passing)... thanks to
"Oz" for the more elucidating expositions on the thermodynamics of chips, but
can we cut this petty insulting behaviour now?

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

In article <8110b9$72u1@gamma.dmz-eu.st.com>, Dave Smith
<dsmith@bristol.nospam.st.com> writes
>In article <DrqGVLArivM4EwLX@provocative.freeserve.co.uk>, Gav 
><Gavin@NOSPAM.co.uk> writes:
>|> You don't appear to have taken anything other than higher clock speed =
>|> higher power dissipation into account. There are a few other reasons a
>|> device has a clock limit, parasitic capacitance for example...
>
>On the contrary, I have taken other things into account.  It is true that higher
>clock speed = higher power dissipation, but higher temperature = higher
>resistance.  As I said in the other post, the delay is a function of resistance
>and capacitance, so if you reduce the resistance, you reduce the delay.
>
>Otherwise, why is it that our SPICE transistor models run faster when they are 
>in colder operating conditions?
>
>If you can get the _die_ of a chip cooler, it will run faster.  This is one of 
>the functions of extra cooling in overclocked systems.  A chip with a die at 10C
>can run faster than a chip with a die at 40C.  Both temperatures are within 
>the safe limits of most chips, so neither is overheating, but the first will 
>have
>intrinsically faster transistors because of the lower temperature.
>
Ah, you're clearly better educated in this subject than I am. I do have
a little background in this area (degree microelectronics, Brunel) but
it's been a couple of years or so now.

I read your post as saying temperature is the only factor affecting
whether a device will overclock. I was thinking back to when we messed
with HSPICE and overclocked a simple synchronous counter, watching as a
screen of nice clean (nearly) square waves degenerated into mere wobbly
lines as the clock rate was upped. The speeds the latest generation of
processors run at never cease to amaze me.
-- 
|Gav|

ICQ# 19875282
gavin@provocative.freeserve.co.uk

Dave Smith wrote:

> In article <f6ps08.c43.ln@stravinsky>, anahata@freereed.demon.co.uk wrote:
> |> Overheating is a separate problem.  It can be a consequence of overclocking,
> |> and overheating can cause errors, but that's not the only reason why an
> |> overclocked device goes wrong. If the logic can't respond fast enough to
> |> have the right data at the output when the next clock pulse arrives, there
> |> will be errors, simply because the internal logic can't move fast enough (at
> |> any temperature).
> 
> Device Speed is always a function of temperature, i.e. the
> hotter it is, the slower it runs.  
...

As Oz says, this is nonsense. I won't duplicate his, correct, 
arguments, but will raise one point which isn't clear from his 
debunking: in a PC, or anything else where timing is determined by a
clocking oscillator, speed is _entirely_ determined by the oscillator
clock speed. If the chips are up to it, it'll work, else not. (The 
"clock speed" heere is nothing to do with the time-of-day clock.) 
"Better" chips, a different temperature, etc. etc. will make ZERO 
difference to running speed at a given clock speed. If the chips 
aren't up to the speed (but otherwise OK), reducing the master clock
speed (i.e., reducing the frequency) will make them work, but at a 
slower speed due to the reduced clock speed. If the chips are having
trouble due to overheating at a given clock speed, cooling may bring
them back to a working state; but no degree of cooling will help if 
the chip simply isn't up to it.

There is an extra issue with memory: to simplify, if memory is too 
slow to run flat out it can often be made to work without slowing 
down the system clock by adding "wait states", which slows down the 
system to some extent.

One related point: there is a relationship which depends upon the 
type of circuit used, between speed and power consumption. heat 
generated depends strictly upon power consumption. Some logic chips 
(TTL) have power consumption independent of operational speed. 
Others, including, I believe, most modern microprocessors, consume 
power more or less proportionally to clock speed. This is why faster 
clock speeds need more cooling: the faster clock causes more power to 
be used.

All else being equal, increasing the voltage of the power supply can 
squeeze a little more speed out of chips (i.e., make them keep 
working at a higher clock speed). It also increases power consumption 
and heat generation, and an excessive voltage itself can do damage 
even without overheating.

The effects of _moderate_ overheating are likely not to be permanent 
(otherwise failure of the processor fan would destroy the processor). 
Overvoltage may or may not produce permanent damage, but it's best 
not to risk it unless using a voltage known to be safe for a 
particular chip.

Best wishes,
-- 
Michael Salem

On 17 Nov 1999 15:00:15 +0000, Robin Smith <smithrc@zdbaora.nat.bt.com> wrote:
>dsmith@bristol.nospam.st.com (Dave Smith) writes:
>
>> Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
>> hotter it is, the slower it runs.  Extra cooling in overclocked machines has two
>> functions:
>>  o Stop the device from exceeding a safe temperature limit, beyond which the chip
>>    can be physically damaged
>>  o Keep the device as cool as possible, to maximise the speed at which it can run
>>    The colder a device is, the faster it will run.
>> 
>
>Bollocks, the phrase "Device Speed is always a function of
>temperature" is wrong. "temperature is a function of device speed" is
>correct. 

You are wrong here. CMOS devices get stronger at low temperature and
as the gate/interconnect capacitance is fixed, they switch more quickly.
Try running SPICE sometime. 

-- 
Andy

Robin Smith <smithrc@zdbaora.nat.bt.com> doodled in uk.comp.os.linux:

> Bollocks, the phrase "Device Speed is always a function of temperature" is
> wrong. "temperature is a function of device speed" is correct. 

You were right in saying you'd just been to the pub.

An inverse function is also a function, as long as ranges, domains and non-
smooth bits are sorted out.

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

On Wed, 17 Nov 1999 17:05:14 +0000, Oz <Oz@upthorpe.demon.co.uk> wrote:
>In article <80ttgr$1aq2@gamma.dmz-eu.st.com>, Dave Smith
><dsmith@bristol.nospam.st.com> writes
>
>>In article <f6ps08.c43.ln@stravinsky>, anahata@freereed.demon.co.uk wrote:
>>|> Overheating is a separate problem.  It can be a consequence of overclocking,
>>|> and overheating can cause errors, but that's not the only reason why an
>>|> overclocked device goes wrong. If the logic can't respond fast enough to
>>|> have the right data at the output when the next clock pulse arrives, there
>>|> will be errors, simply because the internal logic can't move fast enough (at
>>|> any temperature).
>>
>>Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
>>hotter it is, the slower it runs.  
>
>Garbage. You have your cause and effect mixed up.
>Actually IIRC conventional silicon semiconductors run slightly FASTER
>when hot because of a *small* increase in electron/hole speed.
>

I suggest you look at the address Dave writes from. ST is a 
semiconductor manufacturer. I am a semiconductor designer and
fully agree with Dave.


-- 
Andy

In article <14cu08.g51.ln@127.0.0.1>, Anahata
<anahata@freereed.demon.co.uk> writes
>On Wed, 17 Nov 1999 07:28:33 +0000, Oz <Oz@upthorpe.demon.co.uk> wrote:
>
>>>If you overclock, How do you know that everything will work all the
>>>time, in all circumstances, 
>>
>>Even if you don't, how do you KNOW this?
>>You don't. Mostly because things don't always work all the time and in
>>all circumstances whether guaranteed or not.
>
>It's not quite as vague as that.

<snip>

>While these conditions are met, the
>manufacturer can guarantee correct operation.  Note that "guarantee" is not
>scientific proof that it will work; it indicates that the supplier can
>afford to offer you your money back if it doesn't, because any remaining
>failures will be rare

Which is precisely what I said.

>>Your argument is specious in the face of the overwhelming evidence of
>>experience some of which has been posted to this thread.
>
>That's unneccesarily strong.  There are systematic limits to the operating
>conditions, and a chip as supplied and run at the correct clock speed and
>other conditions is very likely to be reliable.

Which does not preclude overspecced devices being labelled as lower spec
to meet demand.

>In other words, at a given clock speed a given chip will either work or it
>won't.  Of course that's not the only hardware reason why a PC may crash,
>but that's another matter.

True insofar as it might mostly work, except when conditions (which can
be complex combinations of levels and noise within the chip) mean it
doesn't. :-)

-- 
Oz

In article <x2emdp17uo.fsf@zdbaora.nat.bt.com>, Robin Smith <smithrc@zdbaora.nat.bt.com> writes:
|> dsmith@bristol.nospam.st.com (Dave Smith) writes:
|> 
|> > Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
|> > hotter it is, the slower it runs.  Extra cooling in overclocked machines has two
|> > functions:
|> >  o Stop the device from exceeding a safe temperature limit, beyond which the chip
|> >    can be physically damaged
|> >  o Keep the device as cool as possible, to maximise the speed at which it can run
|> >    The colder a device is, the faster it will run.
|> > 
|> 
|> I'm just back from the pub so restraint mode=unrestrained
|> 
|> Bollocks, the phrase "Device Speed is always a function of
|> temperature" is wrong. "temperature is a function of device speed" is
|> correct. CMOS only uses current ( generates heat ) when it switches,
|> the faster you switch a CMOS circuit the hotter it gets.

Correct.  What generates this heat?  Resistance.  The capacitance of a device is 
not affected by temperature, but the resistance *is*.  Ironically, the hotter
a device is, the higher the resistance, so the more heat it generates.

|> The phrase "Keep the device as cool as possible, to maximise the speed
|> at which it can run. The colder a device is, the faster it will run."
|> is patently untrue. Keeping the temperature will stop the chance of
|> breakdown by stopping failures due to thermal problems however it will
|> not stop electrical limits ( capacitance etc. ). 

You appear to have forgotten elementary electronic theory.  Simply putting
parasitic capacitance (capacitance between the node you're interested in, and 
ground) in a circuit will not slow it down; the speed reduction is caused by the
combination of capacitance with the resistance of the driving transistor
(resistance of the wire interconnect is also becoming an increasingly important
factor as we move towards deep-sub-micron device dimensions).  The resistance of
the device increases as temperature increases, and the delay is directly
proportional to that resistance.

As I said before, any device will be able to run faster if you can keep it below
it's normal operating temperature (at normal clock speed).

|>                                                   If we could cool the
|> systems enough to make them run fast enough we would be using ZX-81s
|> in liquid nitrogen clocking at 1GHz. Now there is a thought!

If we're going to do that, then use superconducting materials for interconnect...

Anyway, this has now gone waaaaaay off-topic.

-- 
David Smith                   Tel: +44 (0)1454 462380 (direct)
STMicroelectronics            Fax: +44 (0)1454 617910
1000 Aztec West    TINA (ST only): (065) 2380
Almondsbury                  Home: 01454 616963
BRISTOL                    Mobile: 07932 642724
BS32 4SQ               Work Email: dsmith@bristol.st.com
                       Home Email: David.Smith@gazpacho.demon.co.uk

piglet@glutinous.custard.org (Tim Haynes) writes:

> Robin Smith <smithrc@zdbaora.nat.bt.com> doodled in uk.comp.os.linux:
> 
> > Bollocks, the phrase "Device Speed is always a function of temperature" is
> > wrong. "temperature is a function of device speed" is correct. 
> 
> You were right in saying you'd just been to the pub.
> 
> An inverse function is also a function, as long as ranges, domains and non-
> smooth bits are sorted out.

I agree that inverse functions are also functions, but my point is which
causes which.

I agree that devices that operate at a lower temperatures can run
faster than those at higher temperatures ( less scattering from the
lattice, fewer hot electrons ).

But I believe that the statement above is misleading. As the primary
concern of CMOS is that the faster you clock it the hotter it gets.

I for one would never run components in my computer outside of their
specified ranges. Why risk your data for a saving of between 50 UKP
and 200 UKP?

andy+news@DELETE.pteron.demon.co.ME.uk (Andy Repton) writes:

> You are wrong here. CMOS devices get stronger at low temperature and
> as the gate/interconnect capacitance is fixed, they switch more quickly.
> Try running SPICE sometime. 
> 
> -- 
> Andy

I still remember when after things were fabricated people would say
"But it simulated correctly in SPICE!", it was a pile of shite ( 5
years ago ).

Robin

In article <DrqGVLArivM4EwLX@provocative.freeserve.co.uk>, Gav <Gavin@NOSPAM.co.uk> writes:
|> You don't appear to have taken anything other than higher clock speed =
|> higher power dissipation into account. There are a few other reasons a
|> device has a clock limit, parasitic capacitance for example...

On the contrary, I have taken other things into account.  It is true that higher
clock speed = higher power dissipation, but higher temperature = higher
resistance.  As I said in the other post, the delay is a function of resistance
and capacitance, so if you reduce the resistance, you reduce the delay.

Otherwise, why is it that our SPICE transistor models run faster when they are 
in colder operating conditions?

If you can get the _die_ of a chip cooler, it will run faster.  This is one of 
the functions of extra cooling in overclocked systems.  A chip with a die at 10C
can run faster than a chip with a die at 40C.  Both temperatures are within 
the safe limits of most chips, so neither is overheating, but the first will have
intrinsically faster transistors because of the lower temperature.

-- 
David Smith, Silicon Design Engineer  Tel: +44 (0)1454 462380 (direct)
STMicroelectronics                    Fax: +44 (0)1454 617910
1000 Aztec West            TINA (ST only): (065) 2380
Almondsbury                          Home: 01454 616963
BRISTOL                            Mobile: 07932 642724
BS32 4SQ                       Work Email: dsmith@bristol.nospam.st.com
                               Home Email: David.Smith@gazpacho.nospam.demon.co.uk

dsmith@contract15.inmos.co.uk (Dave Smith) writes:

> In article <x2emdp17uo.fsf@zdbaora.nat.bt.com>, Robin Smith <smithrc@zdbaora.nat.bt.com> writes:
> |> dsmith@bristol.nospam.st.com (Dave Smith) writes:
> |> 
> |> > Rubbish (sort of).  Device Speed is always a function of temperature, i.e. the
> |> > hotter it is, the slower it runs.  Extra cooling in overclocked machines has two
> |> > functions:
> |> >  o Stop the device from exceeding a safe temperature limit, beyond which the chip
> |> >    can be physically damaged
> |> >  o Keep the device as cool as possible, to maximise the speed at which it can run
> |> >    The colder a device is, the faster it will run.
> |> > 
> |> 
> |> I'm just back from the pub so restraint mode=unrestrained
> |> 
> |> Bollocks, the phrase "Device Speed is always a function of
> |> temperature" is wrong. "temperature is a function of device speed" is
> |> correct. CMOS only uses current ( generates heat ) when it switches,
> |> the faster you switch a CMOS circuit the hotter it gets.
> 
> Correct.  What generates this heat?  Resistance.  The capacitance of a device is 
> not affected by temperature, but the resistance *is*.  Ironically, the hotter
> a device is, the higher the resistance, so the more heat it generates.
> 
> |> The phrase "Keep the device as cool as possible, to maximise the speed
> |> at which it can run. The colder a device is, the faster it will run."
> |> is patently untrue. Keeping the temperature will stop the chance of
> |> breakdown by stopping failures due to thermal problems however it will
> |> not stop electrical limits ( capacitance etc. ). 
> 
> You appear to have forgotten elementary electronic theory.  Simply putting
> parasitic capacitance (capacitance between the node you're interested in, and 
> ground) in a circuit will not slow it down; the speed reduction is caused by the
> combination of capacitance with the resistance of the driving transistor
> (resistance of the wire interconnect is also becoming an increasingly important
> factor as we move towards deep-sub-micron device dimensions).  The resistance of
> the device increases as temperature increases, and the delay is directly
> proportional to that resistance.
> 
> As I said before, any device will be able to run faster if you can keep it below
> it's normal operating temperature (at normal clock speed).
> 
> |>                                                   If we could cool the
> |> systems enough to make them run fast enough we would be using ZX-81s
> |> in liquid nitrogen clocking at 1GHz. Now there is a thought!
> 
> If we're going to do that, then use superconducting materials for interconnect...
> 
> Anyway, this has now gone waaaaaay off-topic.
> 
> -- 
> David Smith                   Tel: +44 (0)1454 462380 (direct)
> STMicroelectronics            Fax: +44 (0)1454 617910
> 1000 Aztec West    TINA (ST only): (065) 2380
> Almondsbury                  Home: 01454 616963
> BRISTOL                    Mobile: 07932 642724
> BS32 4SQ               Work Email: dsmith@bristol.st.com
>                        Home Email: David.Smith@gazpacho.demon.co.uk


Yes I agree with what you say but the point I'm making is that the RC
time constant is the limiting factor. Assuming you keep R constant by
keeping the chip cool the capacitance is still the limiting factor.
So you cannot clock a device faster than the capacitance allows
( unaffected by temperature ).

So I *assume* INTEL/AMD make their chips and rate them as to how fast
they can safely be run at ( with a bit of tolerance for safety ).

But I also *assume* that if there is a strong demand for slow devices
and their fab facility is making lots of high speed devices and few
slow devices, then some will be relabelled as slow.  Although this
might not make economic sense as if there is a scarcity of slow ones
their price should rise to meet the demand - digression to economics.

This is definitely my last posting about CMOS/heat/RC time constants -
ever!

Robin

P.S. Does Godfrey Gaston work with you? I know he disappeared to the
South of England to work with some silicon company.

In article <x2903vvqzg.fsf@zdbaora.nat.bt.com>, Robin Smith <smithrc@zdbaora.nat.bt.com> writes:
|> Yes I agree with what you say but the point I'm making is that the RC
|> time constant is the limiting factor. Assuming you keep R constant by
|> keeping the chip cool the capacitance is still the limiting factor.
|> So you cannot clock a device faster than the capacitance allows
|> ( unaffected by temperature ).

This is exactly what I am saying (sort of).  You are assuming a constant
temperature.  I am saying that if you lower the temperature of the device (in
particular, lowering the temperature of the die of the device, rather than that
of the package), you lower the resistance, and therefore speed it up. 
Interestingly, you also lower the amount of heat it generates...
 
|> So I *assume* INTEL/AMD make their chips and rate them as to how fast
|> they can safely be run at ( with a bit of tolerance for safety ).

Yes.  Every device will be tested and 'binned' according to it's speed.  The
devices will be labelled accordingly, and the slower devices will be sold off 
at a lower price.

However, Manufacturers *do* change process technologies without telling the
customers.  It is possible, for example, that the 400 MHz parts are made up of
slower devices from the new technology (aimed at 500 MHz), plus the faster ones 
from the old technology (aimed at 400 MHz).  You won't necessarily know which
ones you've got, but the new technology devices are likely to be better for
overclocking.

|> But I also *assume* that if there is a strong demand for slow devices
|> and their fab facility is making lots of high speed devices and few
|> slow devices, then some will be relabelled as slow.  Although this
|> might not make economic sense as if there is a scarcity of slow ones
|> their price should rise to meet the demand - digression to economics.

This is true.  However, they may not derate the faster chips, so that people are
forced to buy the faster, more expensive ones.  There was a scam a few years ago
when people over in the far east were removing the labels from 486DX2-50s, and 
relabelling them as 486DX2-66s, because it was widely rumoured that Intel were 
derating 66 MHz parts to 50 MHz because their yield was so good.

Of course, they will only derate parts if they are unable to sell them at the
higher speed marking...

This is a matter for the economists/market analysts on the list to discuss, not
the engineers :-)
 
|> This is definitely my last posting about CMOS/heat/RC time constants -
|> ever!

Good. It's gone way too far off topic... <g>

|> P.S. Does Godfrey Gaston work with you? I know he disappeared to the
|> South of England to work with some silicon company.

Not AFAIK.  There are *lots* of silicon companies down here now...

-- 
David Smith                   Tel: +44 (0)1454 462380 (direct)
STMicroelectronics            Fax: +44 (0)1454 617910
1000 Aztec West    TINA (ST only): (065) 2380
Almondsbury                  Home: 01454 616963
BRISTOL                    Mobile: 07932 642724
BS32 4SQ               Work Email: dsmith@bristol.nospam.st.com
                       Home Email: David.Smith@gazpacho.nospam.demon.co.uk

On Fri, 19 Nov 1999 at 20:05:03, Tim Haynes
<piglet@glutinous.custard.org> wrote in demon.tech.pc:
(Reference: <slrn83bbbf.eb.piglet@pigsty.td.micromuse.co.uk>)

>Hey! I hope that wasn't meant to be directed at me :8|

On the contrary, I was trying to support your suggestion that a few
other people stop being offensive to each other.
-- 
John Underwood

>|> >Personally, I don't overclock, as I don't need the extra CPU power (I run on 
>a
>|> >DX2-66, by the way...).
>|>  ^^^^^^ Why?
>
>It's fast enough for my needs (Mail, News, a bit of kernel programming
>occasionally).  I see no need to upgrade to the latest hardware.
>

Oh I see!

Shaun Arrowsmith

e-mail me at shaun@home02.demon.co.uk
        or   shaun@FAUN-LTD.demon.co.uk
                

>Personally, I don't overclock, as I don't need the extra CPU power (I run on a
>DX2-66, by the way...).
 ^^^^^^ Why?
Shaun Arrowsmith

e-mail me at shaun@home02.demon.co.uk
        or   shaun@FAUN-LTD.demon.co.uk
                

In article <Mia4NCAwrPN4EwjE@home02.demon.co.uk>, Shaun Arrowsmith <Shaun@home02.demon.co.uk> writes:
|> >Personally, I don't overclock, as I don't need the extra CPU power (I run on a
|> >DX2-66, by the way...).
|>  ^^^^^^ Why?

It's fast enough for my needs (Mail, News, a bit of kernel programming
occasionally).  I see no need to upgrade to the latest hardware.

-- 
David Smith                   Tel: +44 (0)1454 462380 (direct)
STMicroelectronics            Fax: +44 (0)1454 617910
1000 Aztec West    TINA (ST only): (065) 2380
Almondsbury                  Home: 01454 616963
BRISTOL                    Mobile: 07932 642724
BS32 4SQ               Work Email: dsmith@bristol.nospam.st.com
                       Home Email: David.Smith@gazpacho.nospam.demon.co.uk

On Thu, 18 Nov 1999 18:25:13 +0000, John Underwood
<john@jsunderwood.demon.co.uk> wrote:

>
>Would you always know if it had failed to work correctly. For example,
>if overclocking meant that there wasn't enough time for carry bits to
>ripple their way through a register. There are probably other examples.
>Why would an error be reported when, if everything is done according to
>spec, there can be no error.

In theory, that could happen.  However, computers spend much of their time
making address computations, and a simple numerical error in an address is
likely to cause visible effects, either with a progam going out of control
or with the OS trapping an illegal access.

I would expect that in most cases a system will be error free or the error
rate will be high enough that the result will be obvious.

-- 
Anahata
anahata@freereed.demon.co.uk  -+- http://www.freereed.demon.co.uk
020 7229 6076 (H)     0976 263827 (M)    020 7598 0208 (F)
======= brought to you from a Debian 2.1 GNU/Linux system =======

On Thu, 18 Nov 1999 16:08:30 +0000, Oz <Oz@upthorpe.demon.co.uk> wrote:

>> *how* does one determine
>>whether it's speed that affects temperature *or* the other way round
>
>Very simple. See how fast you can run an 8MHz 8086 as you decrease the
>temperature. You will find there is a maximum rate and that this is very
>little affected by temperature simply because the switching speed of the
>components limits the maximum clock speed.

Well, yes and no.  In a way Dave Smith was right when he refuted my
assertion that a chip either works or doesn't work at a given clock speed.
The truth is that there are effects both ways round.  Let's try to summarize
them.

1. Dealing with what you've just said above.  The switching speed of the
components *is* affected by temperature, and I'm prepared to accept, on
Dave's authority as a semiconductor engineer and also because it accords with
my own hazy memory of it when hardware electronics was my job, that devices
tend to get slower rather than faster at higher temperatures.

2. Clocking any given device faster will generate more heat.  That's because
each transition charges or discharges capacitances and dissipates a fixed
amount of energy, so more transitions per second means more energy
dissipated per second (= power)

So when you increase the clock speed of a given chip, the first thing that
happens is you immediately reduce the time budget in the internal logic,
simply because the clock interval is shorter.  The second thing is that the
chip gets hotter, hence slower, which further reduces the time budget.  The
second effect can be cancelled by increasing the cooling sufficiently to
reduce the chip temperature to the same as it was before.  DS is suggesting
that the first effect can also be reduced by overcooling so the chip's
actually cooler that it was before despite higher power disspation.

Personally I suspect that the change in chip speed with temperature is
fairly small, and that short of using elaborate heat pump techniques (like
Intel's first 486-50) you can't make a chip go much faster that it naturally
wants to.  But since I don't have figures to support that, I think we'll
have to accept that to some extent everybody's right in this argument, but
nether side of it is the whole story.

>Really it's only been recent chips that have dissipated enough for the
>package dissipation to be a limiting factor in the permittable maximum
>clockspeed. Hence the use of lower core voltages in an effort to
>restrict dissipation at any given clockspeed (because dissipation is
>roughly proportional to supply voltage).
>
Don't know what you mean by recent, but cooling fans came in with the 486
DX2-66.  You are right about voltages; the other factor that reduces
dissipation is the size of the components on the chip.  Smaller transistors,
less capacitance, less charge shifted on each logic state transition, less
power.

-- 
Anahata
anahata@freereed.demon.co.uk  -+- http://www.freereed.demon.co.uk
020 7229 6076 (H)     0976 263827 (M)    020 7598 0208 (F)
======= brought to you from a Debian 2.1 GNU/Linux system =======

On Thu, 18 Nov 1999 at 21:46:40, Tim Haynes
<piglet@glutinous.custard.org> wrote in demon.tech.pc:
(Reference: <slrn838su0.j2.piglet@pigsty.td.micromuse.co.uk>)

>Oz <Oz@upthorpe.demon.co.uk> doodled in uk.comp.os.linux:
>
>> Your logic is thus totally faulty because the active region of the chip
>> is at the same temperature either way.
>> I could go on but I sincerely hope you don't design chips as you show
>> such profound ignorance of how they behave in a system.
>> You really should learn about junction to ambient heatflows then you
>> could understand what I am talking about. 
>
>Come, come, gentlemen (and any ladies who happen to be passing)... thanks to
>"Oz" for the more elucidating expositions on the thermodynamics of chips, but
>can we cut this petty insulting behaviour now?
>

Hear, hear. I intend to dig out my textbooks and look up the facts. I
won't, however, be sharing the result of my research - some idiot will
tell me I am a fool for believing the wrong text book.

If this is the result of a relatively innocent question about Linux,
Windows starts looking attractive - it certainly seems to produce more
general agreement.

-- 
John Underwood

In article <ORAUqHA3xkL4Ewgo@dbqa.demon.co.uk>, Tom Bird
<hamster@nospam.demon.co.uk> writes
>Get a 366 from ukgamers and do it at 550MHz.  As soon as I get a job,
>I'll ditch the old slow 417MHz I have now to get a 550.  417 is so last
>week.

I'd be a bit careful sending money in ukgamers (PC Gear) direction if I
were you. 

See thread "Warning: ukgamers aka pcgear are liars and frauds" and
numerous similar previous threads in uk.comp.vendors.

Something seems to have gone badly wrong with the company over the last
few months. Steve, the owner and once a regular contributor to uk.c.v
has become very elusive since numerous complaints have been appearing in
the NG. 


-- 
Best regards,

Alan J Webb.

John Underwood <john@jsunderwood.demon.co.uk> doodled in uk.comp.os.linux:

> >Come, come, gentlemen (and any ladies who happen to be passing)... thanks
> >to "Oz" for the more elucidating expositions on the thermodynamics of
> >chips, but can we cut this petty insulting behaviour now?
> 
> Hear, hear. I intend to dig out my textbooks and look up the facts. I won't,
> however, be sharing the result of my research - some idiot will tell me I am
> a fool for believing the wrong text book.

Oh, I wouldn't call you that...

> If this is the result of a relatively innocent question about Linux, Windows
> starts looking attractive - it certainly seems to produce more general
> agreement.

...but I would call you a mad extremist masochist for that, though! :P :)

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

In article <uEs4vBAsxJN4EwEI@jsunderwood.demon.co.uk>, John Underwood
<john@jsunderwood.demon.co.uk> writes

>I intend to dig out my textbooks and look up the facts. I
>won't, however, be sharing the result of my research - some idiot will
>tell me I am a fool for believing the wrong text book.

You aren't supposed to believe textbooks, you are supposed to understand
them.

-- 
Oz

Oz <Oz@upthorpe.demon.co.uk> doodled in uk.comp.os.linux:

> You aren't supposed to believe textbooks, you are supposed to understand
> them.

You obviously haven't read a textbook on (S)ML, then. They take some believing
AND some understanding, IMHO :)
Yes, you are supposed to believe a textbook, at least as insofar as believing
what it tells you is true. Understanding is essential but a lower layer.

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

On Fri, 19 Nov 1999 at 14:19:23, Tim Haynes
<piglet@glutinous.custard.org> wrote in demon.tech.pc:
(Reference: <slrn83an3b.fdv.piglet@pigsty.td.micromuse.co.uk>)

>> If this is the result of a relatively innocent question about Linux, Windows
>> starts looking attractive - it certainly seems to produce more general
>> agreement.
>
>...but I would call you a mad extremist masochist for that, though! :P :)

The madness is an established medical fact :-) (but I don't admit to
masochism).

I did say agreement, I didn't specify that I meant agreement with
Windows, but that we shared, pretty amicably, an opinion of the person,
organisation or whatever else it is that produces it.

-- 
John Underwood

On Fri, 19 Nov 1999 at 14:13:54, Oz <Oz@upthorpe.demon.co.uk> wrote in
demon.tech.pc:
(Reference: <SkJxkJAisVN4EwgH@upthorpe.demon.co.uk>)

>In article <uEs4vBAsxJN4EwEI@jsunderwood.demon.co.uk>, John Underwood
><john@jsunderwood.demon.co.uk> writes
>
>>I intend to dig out my textbooks and look up the facts. I
>>won't, however, be sharing the result of my research - some idiot will
>>tell me I am a fool for believing the wrong text book.
>
>You aren't supposed to believe textbooks, you are supposed to understand
>them.
>
I know, but I was referring to what someone else would say.

-- 
John Underwood

On Fri, 19 Nov 1999 at 16:32:25, Tim Haynes
<piglet@glutinous.custard.org> wrote in demon.tech.pc:
(Reference: <slrn83ausp.fs6.piglet@pigsty.td.micromuse.co.uk>)

>Oz <Oz@upthorpe.demon.co.uk> doodled in uk.comp.os.linux:
>
>> You aren't supposed to believe textbooks, you are supposed to understand
>> them.
>
>You obviously haven't read a textbook on (S)ML, then. They take some believing
>AND some understanding, IMHO :)
>Yes, you are supposed to believe a textbook, at least as insofar as believing
>what it tells you is true. Understanding is essential but a lower layer.
>
I can think of plenty of text books from which, because I do know a
little about the subject, I have refused to believe anything. If you
have a teacher, you may accept that the teacher's recommendation is a
good guide to the reliability of the text book. Otherwise your own
knowledge must inform you to its reliability as a reporter of facts and
then the reliability of its interpretation of those facts.

I agree that understanding is essential and a lower layer - the basis of
everything else, perhaps. Without it the rest is meaningless.

However, this discussion looks like going the way of its predecessor. If
you would like to discuss this further, perhaps elsewhere might be
better. However, if you only want to tell me I am stupid because I
differ from you, hold up a mirror.
-- 
John Underwood

John Underwood <john@jsunderwood.demon.co.uk> doodled in uk.comp.os.linux:

> I agree that understanding is essential and a lower layer - the basis of
> everything else, perhaps. Without it the rest is meaningless.

Too right.

> However, this discussion looks like going the way of its predecessor. If
> you would like to discuss this further, perhaps elsewhere might be
> better. However, if you only want to tell me I am stupid because I
> differ from you, hold up a mirror.

Hey! I hope that wasn't meant to be directed at me :8|

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| Flags	: 	fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

In article <g49318.at.ln@127.0.0.1>, anahata@freereed.demon.co.uk (Anahata) writes:
|> On Thu, 18 Nov 1999 18:25:13 +0000, John Underwood
|> <john@jsunderwood.demon.co.uk> wrote:
|> In theory, that could happen.  However, computers spend much of their time
|> making address computations, and a simple numerical error in an address is
|> likely to cause visible effects, either with a progam going out of control
|> or with the OS trapping an illegal access.
|> 
|> I would expect that in most cases a system will be error free or the error
|> rate will be high enough that the result will be obvious.

Not necessarily.  You do not know where the critical path(s) (the section of the 
chip which is closest to being broken) is located.  If it is in logic which is
used for address calculation, then you will probably notice an error quickly.  If
it is in the microcode, then you will almost certainly notice it.  However, it
could be somewhere a bit more innocuous; it is quite possible that the failure 
could be located in the FPU, given their complexity. Or maybe in the path
writing data out to memory.  If you are doing tax rate calculations, which would 
probably use the FPU, then you might get unnoticed errors in your data.  I'm not
sure I'd like to take the risk of corrupting the data going through my CPU. It's
a matter of personal choice whether you overclock or not.

Incidentally, when you get close to the limit of the speed of the device, there 
are other factors which could cause errors - crosstalk, for example, is where 
two wires run parallel together for a reasonable distance.  The capacitance 
between the two wires means that if they both change state at the same time, 
they will each affect the speed of the other.  
If both wires change from 0 to 1, then they will change particularly fast, 
whereas if one changes from 0 to 1 and the other changes from 1 to 0, then 
they will both change particularly slowly.  Factors like this are enough to 
push the delay  'over the edge'.  So, whether your device fails depends not 
only on what it is doing at the time, but also the data you are using.  

-- 
David Smith                   Tel: +44 (0)1454 462380 (direct)
STMicroelectronics            Fax: +44 (0)1454 617910
1000 Aztec West    TINA (ST only): (065) 2380
Almondsbury                  Home: 01454 616963
BRISTOL                    Mobile: 07932 642724
BS32 4SQ               Work Email: dsmith@bristol.st.com
                       Home Email: David.Smith@gazpacho.demon.co.uk

In article <7XRLoHAAGGN4EwWM@upthorpe.demon.co.uk>, Oz <Oz@upthorpe.demon.co.uk> writes:
|> In article <3833dc8c.0@nnrp1.news.uk.psi.net>, Andy Repton <andy+news@DE
|> LETE.pteron.demon.co.ME.uk> writes
|> Firstly the junction temperature of a normal spec chip with normal
|> cooling is probably about 100C or thereabouts. The junction temperature
|> of a clocked up chip which of course dissipates much more but with a
|> supercooling of the chip will STILL be about 100C or thereabouts. If not
|> and the process permits higher speed then clock it some more.
Ok, let's look at a scenario.

You have a chip, called the X400.  It's specced to run at 400 MHz, with normal
cooling.  Under these conditions, the die will be at 100 C.  However, you know 
that the semiconductor manufacturer has left a 25% safety margin on its timing,
so you know that a device will run at 500 MHz at 100 C die temperature.  So, you
crank up the clock speed to 500 MHz, and put on a couple of extra fans, which 
will keep the die temperature down to 100 C.  All you are doing here is eating
into the manufacturer's safety margin. 

It is true that most overclocked devices will run with a die temperature of 
about 100 C; this is because people are generally unadventurous with their
cooling systems.  They are not getting the benefit of cooler, faster devices 
because they simply do not add enough cooling.

However, you also know that, if you could get the die temperature down to 40 C,
the resistances in the device will be halved. Now, as the speed of the device
depends on the time constant, RC, halving the resistance will halve the delay
within the chip, allowing the chip to run at twice the speed.

So, you increase the clock speed to 1 GHz, and then strap on enough extra cooling
(fans, Peltier heat pump, refridgeration system, bathe in liquid nitrogen/helium/
etc.) to get the temperature of the die down to 40 C (this will probably mean 
that the case will be somewhere around 0 C or lower), then hey presto! You have a
1 GHz device.

Now, to tackle your point "If not and the process permits higher speed then clock 
it some more".  If you were to increase the clock speed beyond 1 GHz, this would 
break the device in two ways:

  o You are already at the maximum speed that the chip can run.  Data is expected
    to arrive ready for the next clock edge within 1 ns.  Increasing the clock 
    speed will mean an even tighter constraint, and the data simply won't get
    there in time.

  o Increasing the clock speed will cause the device to dissipate even more heat,
    warming it up.  This will slow down the transistors, and mean that the device
    isn't even able to meet 1 GHz any more.

Note: these numbers are made up.  They don't reflect reality, they just made the
maths easier.  They do, however, illustrate the point.

|> Your logic is thus totally faulty because the active region of the chip
|> is at the same temperature either way.

Like I said, this is true with a simple cooling mechanism like most people use.
They simply don't add enough cooling to get the die below 100 C.  They lack
imagination (and/or money).  They are simply eating up the safety margin, rather
than making the chip faster.

|> I could go on but I sincerely hope you don't design chips as you show
|> such profound ignorance of how they behave in a system.
|> 
|> You really should learn about junction to ambient heatflows then you
|> could understand what I am talking about. 

A few years ago, I did some characterisation experiments on an HCMOS device, using
a thermostream (a bit of kit that is able to squirt a high-speed stream of air on 
to a device at any temperature you like, between about -25 C and +125 C.  Looks
a bit like a cubic elephant, and runs on electricity and compressed air).
Unsurprisingly, when I cooled the device with -25 C air, it was able to run faster
without errors than when I blasted it with air at  +20 C or +70 C.  If, as you 
say, the die will always run at 100C, then the speed at which I get data errors 
should be the same no matter what temperature air I use.  I've probably got the
results lying around in a log book somewhere.  
I can only draw two possible conclusions from these results:

  1 CMOS devices run faster when they are colder, like I've been trying to say,

or

  2 A month or so of my life is just a figment of my imagination.

Given that questioning one's own sanity is a path I don't wish to go down, I
conclude that option 1 is correct, unless you would like to explain another 
reason why I got these results?

BTW:This will be my last post on the subject, as it has already got too out of 
    hand.

-- 
David Smith                   Tel: +44 (0)1454 462380 (direct)
STMicroelectronics            Fax: +44 (0)1454 617910
1000 Aztec West    TINA (ST only): (065) 2380
Almondsbury                  Home: 01454 616963
BRISTOL                    Mobile: 07932 642724
BS32 4SQ               Work Email: dsmith@bristol.nospam.st.com
                       Home Email: David.Smith@gazpacho.nospam.demon.co.uk

John Underwood <john@jsunderwood.demon.co.uk> doodled in uk.comp.os.linux:
> On Fri, 19 Nov 1999 at 20:05:03, Tim Haynes
> <piglet@glutinous.custard.org> wrote in demon.tech.pc:
					  ^^^^^^^^^^^^^ I did? Coo, I hoped
					  leafnode was dropping that!

> >Hey! I hope that wasn't meant to be directed at me :8|
> 
> On the contrary, I was trying to support your suggestion that a few
> other people stop being offensive to each other.

Coolies, nae worries, sowwy for misunderstanding, here have an extra strong
mint :8]

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++ 
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-	     
| Flags	: 	fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
| The sun is melting over the hills,         | http://www.glutinous.custard.org
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org

In article <81654r$72u4@gamma.dmz-eu.st.com>, Dave Smith <dsmith@contrac
t15.inmos.co.uk> writes

>If you are doing tax rate calculations, which would 
>probably use the FPU, then you might get unnoticed errors in your data.  

The ability of the manufacturers to test all parts of their chips is
very limited. Consequently they would be mad to use close-tolerance chip
design in areas they cannot properly test. You *ought* therefore to be
quite confident that the internal error checking within the CPU chip
will catch problems or be largely immune in the event of an internal
failure. Remember that even good devices operated within their spec will
and do fail and .001% of 100M devices is a heck of a large number of
failures. If they resulted in untrapped errors in financial software of
a large-medium sized company the costs might be eye-watering. 

Judging from the apparent resistance of overheated (and thus failed in
use) processors that have been mentioned in dtpc over the years that
have (on reinstallation of a new fan) gone on for years without problem
I suspect that the manufacturers have sensibly included a chip shutdown
in the event of this sort of gross problem. After all it would only
require a minute percentage of the total components on the chip to
implement this sensible facility (ie just switch off the clock).

I don't believe that for the average user, using known clockable chips,
and with the usual checks is under any great risk for non-critical
usage. If they do have a critical use then saving a few $10's is not an
issue.

>I'm not
>sure I'd like to take the risk of corrupting the data going through my CPU. It's
>a matter of personal choice whether you overclock or not.

If you even use a computer you run the risk of corrupted data. The
decision is to what level of assurance your usage is required to
achieve. This might go from triple (or more) paralleled processors with
voted error correction/checks for operating a remote spacecraft to
grossly overclocked systems when using the latest game. In the former a
failure tends to be rather terminal and the latter a slightly irritating
reboot every week or so.

-- 
Oz

In article <8167ih$72u5@gamma.dmz-eu.st.com>, Dave Smith
<dsmith@bristol.nospam.st.com> writes

>Ok, let's look at a scenario.
>
>You have a chip, called the X400.  It's specced to run at 400 MHz, with normal
>cooling.  Under these conditions, the die will be at 100 C.  However, you know 
>that the semiconductor manufacturer has left a 25% safety margin on its timing,
>so you know that a device will run at 500 MHz at 100 C die temperature.  

That's how old chips worked because the processes limited the speed.
Very few people tried to overclock 486's because it basically didn't
work as the timeconstants and switching speeds were the limiting factor.

>So, you
>crank up the clock speed to 500 MHz, and put on a couple of extra fans, which 
>will keep the die temperature down to 100 C.  All you are doing here is eating
>into the manufacturer's safety margin. 

This would be true if you were switching speed limited. It would not be
true if you were thermally limited. Generally when overclocking one is
talking about a chip that, say, is made with a process that delivers (in
your case) 500MHz devices, but the limiting factor is the size of the
gate capacitance. These are invariably made as small as possible and so
are at the limits of mask technology and thus subject to the greatest
manufacturing variability. Unfortunately on a modern multi-million
device processor the gate capacitance largely determines the power
consumption. So in fact the selection is more on power consumption
rather than speed. The last time I saw the raw switching speed of a
processor component mosfet it was well into the picosecond range.
Usually (invariably?) the tracks are to a much lower tolerance and are
very much larger than the gate channel.

>It is true that most overclocked devices will run with a die temperature of 
>about 100 C; this is because people are generally unadventurous with their
>cooling systems.  They are not getting the benefit of cooler, faster devices 
>because they simply do not add enough cooling.
>
>However, you also know that, if you could get the die temperature down to 40 C,
>the resistances in the device will be halved. Now, as the speed of the device
>depends on the time constant, RC, halving the resistance will halve the delay
>within the chip, allowing the chip to run at twice the speed.

Vastly too simplistic. It's rarely true for modern chips that this is
true because the clock speed is not usually limited by simple RC
constants. That's more true of simple circuits you build on a
breadboard. 

>So, you increase the clock speed to 1 GHz, and then strap on enough extra 
>cooling
>(fans, Peltier heat pump, refridgeration system, bathe in liquid 
>nitrogen/helium/
>etc.) to get the temperature of the die down to 40 C (this will probably mean 
>that the case will be somewhere around 0 C or lower), then hey presto! You have 
>a
>1 GHz device.

Laf! 

>Now, to tackle your point "If not and the process permits higher speed then 
>clock 
>it some more".  If you were to increase the clock speed beyond 1 GHz, this would 
>break the device in two ways:
>
>  o You are already at the maximum speed that the chip can run.  Data is 
>expected
>    to arrive ready for the next clock edge within 1 ns.  Increasing the clock 
>    speed will mean an even tighter constraint, and the data simply won't get
>    there in time.

Unfortunately we aren't typically discussing chips whose raw switching
speed is the limiting factor. We are talking about chips that CAN
process at higher speeds but which are thermally limited, which is the
normal situation with modern CPU's.

>  o Increasing the clock speed will cause the device to dissipate even more 
>heat,
>    warming it up.  This will slow down the transistors, and mean that the 
>device
>    isn't even able to meet 1 GHz any more.
>
>Note: these numbers are made up.  They don't reflect reality, they just made the
>maths easier.  They do, however, illustrate the point.

They might have done, about ten years ago.

>
>A few years ago, I did some characterisation experiments on an HCMOS device,

Right. A LSI chip characteristic assumed to be identical to the tiny and
very busy core of a modern CPU. A dangerous assumption I would suggest.

> 
>using
>a thermostream (a bit of kit that is able to squirt a high-speed stream of air 
>on 
>to a device at any temperature you like, between about -25 C and +125 C.  Looks
>a bit like a cubic elephant, and runs on electricity and compressed air).
>Unsurprisingly, when I cooled the device with -25 C air, it was able to run 
>faster
>without errors than when I blasted it with air at  +20 C or +70 C.  If, as you 
>say, the die will always run at 100C, then the speed at which I get data errors 
>should be the same no matter what temperature air I use.  I've probably got the
>results lying around in a log book somewhere.  
>I can only draw two possible conclusions from these results:
>
>  1 CMOS devices run faster when they are colder, like I've been trying to say,
>
>or
>
>  2 A month or so of my life is just a figment of my imagination.

No, unfortunately it's obsolete knowledge, things have moved on.
Mind you your experience is precisely what I would expect were the HCMOS
chip to have been thermally limited. It's also precisely what I would
expect from a LLI chip with 'power' output circuits that WERE RC limited
and running with risetimes appropriate to the clock used.

>Given that questioning one's own sanity is a path I don't wish to go down, I
>conclude that option 1 is correct, unless you would like to explain another 
>reason why I got these results?

Oh, I could add a whole bunch more, however comparing a LSI HCMOS device
designed to work at 100MHz or less with a VHSI processor designed to
work at close to 1000MHz is a risky assumption.

>BTW:This will be my last post on the subject, as it has already got too out of 
>    hand.

Oh, just when I was enjoying myself.

-- 
Oz

Though S3 Trio 3D is supported by XFree86 3.3.5, but I am not able to
set the Xserver to 16 bit colors, though it says the default setting is
16 bit and 1024*768 resolution, but only 8 bit colors work and that too
with only 1024*768 resolution and lower. Can anybody tell me whether he
has been able to set that to 16 bit color with S3 Trio 3D card and 3.3.5

-apurva


In article
<Pine.LNX.4.10.9911121103320.780-100000@laptop.jasonclifford.com>,
  Jason Clifford <jason@dlsl.demon.co.uk> wrote:
> On 10 Nov 1999, Raphael Mankin wrote:
>
> > :       4Mb AGP S3 Trio
> >
> > DON'T. Getting drivers is a pig.
>
> ?? Drivers? The AGP S3 Trio cards are supported by XFree86 already.
Even
> the S3 Trio 3D is now supported as of 3.3.5
>
> Jason Clifford
http://www.definitelinux.com/
>       Definite Linux - The UK's leading distribution with crypto
support
>                **** Linux Workstation and Server Systems ****
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

On Fri, 26 Nov 1999 06:09:08 GMT, Apurva Prakash <apurva@rocketmail.com> wrote:

> Though S3 Trio 3D is supported by XFree86 3.3.5, but I am not able to set
> the Xserver to 16 bit colors, though it says the default setting is 16 bit
> and 1024*768 resolution, but only 8 bit colors work and that too with only
> 1024*768 resolution and lower. Can anybody tell me whether he has been
> able to set that to 16 bit color with S3 Trio 3D card and 3.3.5

I've got the same card here. I first got going with it with 3.3.4 and back
then the docs stated that you could either have it in 8bit or 24bit and,
even then, the resolution choices were limited. I don't have a pointer to
this info to hand but if you look on the XFree86 web site you should find it
(that's how I found it).

I don't know if this limitation has changed with 3.3.5, I only started using
it on Monday so I'm still running with my 3.3.4 oriented configuration which
gives me 1280x1024 at 24bit. This does mean that Netscape only displays b&w
toolbar icons but I can live with that.

Anyway, have a good scan of the XFree86 docs and the hardware information
lists on the XF86 web site, you'll find the info you need.

-- 
Take a look in Hagbard's World: | boxquote.el - "Boxed" text quoting.
http://www.acemake.com/hagbard/ | binclock.el - emacs binary clock.
http://www.hagbard.demon.co.uk/ |  uptimes.el - Record emacs uptimes.
emacs software, including.......| quickurl.el - Recall lists of URLs.