2 ?? 4 Cathar

[Blackeagle]

I recall you saying you could improve the performance for the P4 larger size CPU when developing the Cascade, but you did not as it would have degreded performance on the T-bred/Barton sized cores. With the two Athlon 64 CPU's now out & incorporating a larger die & IHS will you produce a rev. 2 Cascade optimised for these larger CPU's?

And how is progress coming for the GPU block?

[Cathar]

I've been monitoring the P4 situation and there are a few issues:

P4's are bizarre things when it comes to reporting temperatures, and the temperature that they report does not seem to be indicative of the peak temperature that the die itself will reach.

I've been in contact with a number of people who have been reviewing the Cascade on P4's against other blocks. In some circumstances the Cascade will report equal, or sometimes even higher temperatures than a competing block, and the reviewers quiz me on why this would be the case. I then ask that they do a peak overclock comparison, and lo and behold, the Cascade is allowing the P4's to remain stable at higher reported temperatures.

Why is this so? The reported temperature is the same or slightly higher, but the CPU is clearly being cooled better.

This leads to confusion. People who trust just the reported temperatures seem to think that the Cascade isn't doing its job, but almost invariably, it's doing a better job than what's indicated by temperature alone.

This also confused me a bit too. I was under the impression that perhaps the Cascade could be doing better on a P4 with an IHS, but it seems that its super-focused approach is doing the job properly, just that the temperatures don't always seem to indicate it. Blocks that focus more on cooling the entire IHS, rather than just the central hot CPU die area can achieve comparative temperatures to the Cascade, yet the Cascade still allows an equal or higher overclock, even at higher ambient temperatures.

So I'm left with the evidence that's available pointing to the Cascade doing its job quite well with the IHS CPU's.

There's also a second slant to this. I'm a hobbyist. I want a waterblock that can cool the CPU as well as possible. If you're passionate about water-cooling, like I am, then cooling a CPU with an IHS is like making love with a 1.5mm thick rubber condom on. Sure, you're doing the job and protection is provided, but there's so much more on offer with a bare experience.

So here's my approach to this. The current Cascade revision really is doing its job just fine for IHS CPUs, arguably still the best at the job presently despite what current IHS P4 reported temperatures say. If, however, you want the most out of your block (and CPU) then take the IHS off, and you will have a block that is purpose built for that particular scenario.

I choose not to make my blocks specifically to cater for the lowering of reported temperatures for some scenarios, and instead choose to focus on making blocks by the design methodology that I still believe very firmly in, and that there's plenty of evidence to support my stance.

BTW, the current Cascade's are Rev 2. Rev 1 never made it into "production".

The GPU block is on indefinite hold as I am drastically short of time to even attend to handling Cascade orders, let alone a second line of blocks. Having a real job and a family tends to eat most of one's week.

[nikhsub1]

I can testify to the weirdness of the IHS. I have a Cascade, a Cascade SS and a WW. With my IHS on, there was really no difference in reported temps (as Cathar mentioned) between a Cascade, a WW and a TC-4. I decided to remove the IHS and go bare die on my CPU. Not only did I drop 4 - 5C, but now, even minute differences can be detected such as mounting variations. I really don't think I will ever use an IHS again. As long as you are careful and use a WB (not an air cooler) then there really is no point to the IHS in my mind.

[leejsmith]

although i have not removed my IHS yet my system reported the same temps with a cathar cascade and my diy cascade.

i know my diy cascade is 2C lower temps than a maze 3 so the cascade should be st least 5 lower than it reports.

i have a thermocouple on the side of the IHS and that gives me 6C lower with the cathar cascade than my diy version.

it looks like some motherboars calculate the cpu temps based on cpu speed , core volts and system temp.

[nikhsub1]

And not all P4 boards read the on die sensor either. My IC7 happens to be one of the few that I know does. With insocket probes, pretty much all is hopeless. I'm not saying my temps are accurate but what I feel the on die gives me is a good idea of relative temp differences.

[winewood]

quoted from Cathar
I've been in contact with a number of people who have been reviewing the Cascade on P4's against other blocks. In some circumstances the Cascade will report equal, or sometimes even higher temperatures than a competing block, and the reviewers quiz me on why this would be the case. I then ask that they do a peak overclock comparison, and lo and behold, the Cascade is allowing the P4's to remain stable at higher reported temperatures.

So, based on this logic, the current testing measures of using a bench test or.. die simulater cannot be used for test the Cascade. It seems that every other block in the past, this was good enough. However, temperature no longer is the limiting factor to performance. What is then? Because, if we use this for other blocks and declare them (X). Then what if they are much more efficient using the "non-tempurature" equation?

I think its only fair to point this out, that this seems like a double standard. Because the LRWW temperatures were accepted when they reported the good numbers. But for the Cascade, the same measurements can't? I know its a different block, but now others must accept different testing standard?

Its also funny, how no-one else challenges statements like this, but when others say this, they jump on number reporters like white on rice.

quoted by leejsmith
i know my diy cascade is 2C lower temps than a maze 3 so the cascade should be st least 5 lower than it reports.

Ok.. have to call the BS-o-Meter. What if I say my my temperature says its higher, but it must be 30C lower because someone said so, but multiple reviewers report equal or higher temps.

The conclusion is this. If the current testing proceedure using die sims isn't right using an IHS, then tell us how to fix it, proof that temperatures don't matter can't just change in one block no matter who it is. My recommendation is that we put a IHS on the die. Ignoring it isn't practical. Until a standard is accepted for all, or the IHS on the P4, then anyone stating exemptions must tell us how we can measure it.

[Cathar]

winewood, I think I said it best above when I said:

P4's are bizarre things when it comes to reporting temperatures, and the temperature that they report does not seem to be indicative of the peak temperature that the die itself will reach.

Meaning that the issue is more to do with the way that a P4 CPU reports temperatures. The issue here is a systemic one.

This does NOT preclude testbench simulators set up correctly that do accurately plot the peak temperature of the simulated die.

i.e. the issue is that the P4 does not do this. I find it quite absurd that many P4's will report CPU die temperatures, under load, in the low 40's when overclocked & over-volted and using air-cooling in a 25-30C case temperature. Such low temperatures simply are not practical, and this further heightens my suspicions that P4's absolutely do not track & report what the peak die temperature is, but rather some secondary temperature that is affected in a large way by the temperature of the IHS. Now all this means is that the P4 thermal probe could be off in one far corner of the die away from the bulk of the CPU's heat generation areas, and in close proximity (vertically) to the IHS.

So, this then in my mind is a stronger argument for why "real world" results do not indicate reality, and is a stronger argument for why testbed simulators, with the thermal probe sitting in the centre of the die area, is a more realistic way to see what is going on.

With regards to Athlon64's, I don't know if AMD have put their on-die thermal probe in a better spot. Time will tell.

Most testers only use the tools at their disposal, typically being a real-world P4 system, but this then brings along all the vagaries of the P4 thermal probe accuracy and reporting.

Herein lies the quandary. When designing a waterblock, what should someone aim for?

1) The best results according to a flawed measurement-system benchmark?
2) A waterblock that offers the best results, which can sometimes be at odds with what a single "benchmark" can pick up?

Again, that the Cascade is typically allowing users to either overclock higher, or to sustain a higher overclock at higher room temperatures (summer vs winter), to me, is more indicative that it is cooling better, than a poorly placed P4 thermal probe that reports temperatures which do not seem to align with fairly well understood thermal theory.

[joemac]

It does not make sense why a P4 temperature measurement would be so far off. After all doesn’t the P4 “throttle” base on die temperature. From what I have heard the A64 also employees a similar method to keep temps within a desired range. Indeed a very interesting dilemma…

[Cathar]

Originally posted by joemac
It does not make sense why a P4 temperature measurement would be so far off. After all doesn’t the P4 “throttle” base on die temperature. From what I have heard the A64 also employees a similar method to keep temps within a desired range. Indeed a very interesting dilemma…

The P4 throttling is controlled by a separate diode.

As stated in the P4 documentation, one cannot use the reported temperatures (as given by the THERMDC and THERMDA) pins, which is what motherboards use, to predict the behavior of thermal throttling, or THERMTRIP (CPU thermal shutdown).

XBitLabs ran a rather interesting test. Intel have stated that THERMTRIP is set to trigger when the peak die temperature (as measured by a separate "hidden" internal diode that the motherboard cannot read) reaches around 130-135C.

XBitLabs turned off thermal throttling and stuck their system in a temperature controlled environment and turned off the heatsink fan.

THERMTRIP was triggered (remember, at a 130-135C peak die temperature) when the motherboard (THERMDC/DA) was reporting a mere 92C.

i.e. the peak die temperature was up to 40C higher than the reported temperatures that the motherboards have access to via the Intel thermal sensor pins.

This is part of the evidence that I've been gathering that tells me that P4's do not report correct temperatures, and more importantly, do not report just how hot the CPU really does get.

[joemac]

According to Intel spec sheets:
To allow for the optimal operation of Intel processor based system the thermal solution should be design so that the temperatures remain within the minimum and maximum case temperature specifications (Tc). Intel defines the case temperature at the geometric top center of the processor I.H.S.
Removing the I.H.S will pretty much void all of Intel thermal spec’s as they are based on using the I.H.S. I don’t know but even I would hesitate on removing my I.H.S on my new CPU that I just spend $500 + just to say – look it’s more like a die sim now.

ftp://download.intel.com/design/Pent...s/29864310.pdf

[winewood]

So, here is the inevitable question. Since the temperatures on the p4 can totally be abandoned. Why would anyone test a cascade on a p4 setup. AND if the testbench using a diesim w/out IHS cant replicate a IHS which is the new environment, how can anyone test the cascade? The overclock would vary with each mobo, northbridge, memory etc....

How do we know the cascade is suitable for use with an IHS as a blanket statement? How can we tell ANY block is good for an IHS as any kind of statement?

Thats quite a quandry there. So, without this accurate testing, how was anyone able to come up with "2C under the white water" as a statement? Was that just on an AMD tbird?

[bigben2k]

It sounds like a job for... the WBTA! (coming soon: www.wbta.us )

Obviously the internal diode is placed inside the Intel die to serve its own purpose: to protect the CPU, not to let you know your CPU temp. Since Intel doesn't really care for people to know about a measurement that's more to the point (the hidden diode), they let you see the other diode that they conveniently attached away from the hottest spot.

The solution is to perform a test with a heat die. The problem I still have is where to put the probe within the die (pHaestus: did you get my pm?).

[joemac]

Originally posted by bigben2k
It sounds like a job for... the WBTA! (coming soon: www.wbta.us )


The solution is to perform a test with a heat die. The problem I still have is where to put the probe within the die (pHaestus: did you get my pm?).

Hope this helps.. Should be creditable considering the source

[winewood]

That answers it, but frankly I don't see how the WBTA is addressing the issue of the IHS. In fact I think the plans are to make believe it isn't there. Not a real solid plan IMHO.

[Cathar]

Originally posted by joemac
According to Intel spec sheets:
To allow for the optimal operation of Intel processor based system the thermal solution should be design so that the temperatures remain within the minimum and maximum case temperature specifications (Tc). Intel defines the case temperature at the geometric top center of the processor I.H.S.
Removing the I.H.S will pretty much void all of Intel thermal spec’s as they are based on using the I.H.S. I don’t know but even I would hesitate on removing my I.H.S on my new CPU that I just spend $500 + just to say – look it’s more like a die sim now.

ftp://download.intel.com/design/Pent...s/29864310.pdf

Problem is, Tc is just an arbitrary test temperature, and nothing actually reports it. It is of use to a test setup whereby a channel has been cut into the IHS or heatsink to place a thermocouple in that location. The temperatures that the P4 reports is not Tc.

There's nothing wrong with using a die simulator which includes an extra IHS style device to test waterblock performance for IHS scenarios, and this would indeed be desirable as to date I'm not aware of a single publically visible testbed which has ever done this.


Winewood - addressing your questions:

Why would anyone test a cascade on a p4 setup?

I believe that the question actually applies to most any cooling device, not just the Cascade in particular. Why would anyone test a cooling device on a P4 with it reporting temperatures in the way that it does? At the very least, one would require a Tc style setup as described above to get the beginnings of a semi-accurate P4 test scenario if one truly wanted to determine what is going on with a P4.

AND if the testbench using a diesim w/out IHS cant replicate a IHS which is the new environment, how can anyone test the cascade?

Well, an IHS is just a 1.5mm thick piece of copper sitting atop a die. It really isn't that hard to grab a 1.5mm thick piece of material and stick it atop one's bare-die simulator, and then use that to predict the performance of a cooling device in an IHS scenario. Again, such issues are not restricted to the Cascade, it's just that the Cascade exercises a flaw in the way in which P4's calculate and report their temperatures.

The overclock would vary with each mobo, northbridge, memory etc....

This is true. However, the stability a particular overclock on any given motherboard/CPU/setup tends to be very closely tied to the peak die temperature of the CPU. One cannot predict if something will overclock better, but one can predict the range of water temperatures (affected by ambient temperature presumably) over which a particular overclock will remain stable. People like to overclock in summer just as well as they can overclock in winter. If a waterblock is able to better provide a stable summer overclock, then that can be just as desirable as, and probably more so than, a waterblock that reports xC lower temperatures.

How do we know the cascade is suitable for use with an IHS as a blanket statement? How can we tell ANY block is good for an IHS as any kind of statement?

Quite correct. How do we know that anything is suitable for use with an IHS as a blanket statement? We don't. We look to people's experiences usually to find out.

So, without this accurate testing, how was anyone able to come up with "2C under the white water" as a statement? Was that just on an AMD tbird?

Well, the actual statement that I always quoted was something like this:

"The reference Cascade performed very close to 2C better than my reference White Water on a T'Bred B & Barton CPUs. The motherboard used was an Abit NF7-S Rev2.0. The CPU's were run at 2.4GHz/1.90v, using BurnK7 as a CPU load program, and on my setup"

Others tended to summarise that down to an over-simplification of "the Cascade is 2C better than the White Water".

Truth of the matter is that it's not that simple. People's experiences always vary, just because there are so many variables. As far as I'm aware though, not a single person who owned a White Water and then grabbed a Cascade has seen the Cascade ever perform worse. Some see the same or a very small (~1C) improvements (typically P4 users) but do report that they can either overclock higher, or that the CPU is now more stable across a broader range of conditions when overclocked to the edge. Some see 1-2C, typically on AMD's, but even on P4's with IHS's, and the lower values tend to be with people who barely over-clock/over-volt at all, and the upper values with people who do. I've heard one person say they saw a 4C improvement on an AMD setup. I don't personally believe that such is possible under properly controlled conditions, but the person was very happy.

So what's the answer here?

If it's about that values that a test-bed spits out, one needs to be pretty sure that those values do reflect what is really going on. On P4's, one can be pretty sure that they're well off the mark.

If it's about public perception, and I won't lie much of the Cascade's "status" really is based on perception, then we go by what people report, and almost without exception it's been positive, with no one saying "I've been mislead", or "The Cascade fell well short of my expectations".

When people ask me for my take on the situation, I just want to make a block that at the end of the day I am proud to have on my system, and that I truly believe will offer the best cooling for my system. I have Intel and AMD setups here. I'm just a hobbyist who is happy to provide the same blocks that I made for myself. This is not marketing/money-making for me. If people stopped ordering blocks from me tomorrow, I'd still be happy.

[winewood]

good answer!

man.. your good.

Well, I certainly appreciate the one on one, and the fact that you addressed all my questions. I sure wish I had you to help me explain to the WBTA that the IHS would be a good thing. I'm hitting a low ceiling, and I am not sure myself if a block performing on a TBird is comparable to an IHS without attempting to simulate it. No one wants to really brave it, but they want to continue to test. Very mixed emotions. Cathar, would you be willing to stop by the die sim discussion and help these guys find a way to integrate an IHS?

My favorite idea is to machine a die top that has an internal support structure the size of a core and leave a IHS sized piece of copper unmilled on top of it. Without it, I think we are finding answers that require an "*" beside them, and therefore devoiding them of any real meaning.

[Cathar]

Originally posted by winewood
Cathar, would you be willing to stop by the die sim discussion and help these guys find a way to integrate an IHS?

Hmmm, an IHS should be a separate piece of material that sits on top of the die, and introduces its own thermal interface specifics. Machining it out of a single piece of copper with the die physically "attached" means that there is no thermal disjunction between the die and the IHS. This may not be what you want as it's a different scenario to the way IHS's are, which are simply bits of metal stuck atop a die with some thermal goop in between.

Of course, this then introduces an extra variable, that being ensuring that the thermal interface layer between the IHS and the CPU is consistent between multiple test instances. The thickness of the IHS is another variable. The thicker the IHS, the greater the lateral spread of heat through the IHS in terms of the contact patch between the cooling device and the IHS. One would need to ensure that the thickness of the IHS was matched with either a P4 and an AMD64 IHS, or there may be a fairly happy middle ground if their IHS's are fairly close in thickness.

No real easy answer here. IHS simulation is almost another form of art over and above getting the die simular setup properly. Yes, it'd be nice if the WTBA could do it, but I think getting the die simulator set up properly first, and then introducing an IHS piece later is perhaps the correct way to do it.

[bigben2k]

That sums it up pretty well.

The IHS really doesn't spread heat laterally all that far, so using a heat die similar in size to the P4 die is, in my opinion, acceptable. The problem, or, where I'm stuck, is how to reproduce the temperature measurement, or more specifically, where to take it, within the die.

Then the issue becomes: what adjustment factor does one use, to account for an IHS? First, there's the thickness of the IHS (is it really 1.5 mm?), then there's the curvature in the Intel IHS that becomes flat with clamping, then there's the TIM joint, then there's the silicone, up to the internal diode.

I could compare any AMD to the heat die, but an Intel P4 is a real puzzler. Bottom line, each tester is going to have a different temperature: that's why we have cross testing: so that we can all figure out how off we all are from a CPU temp reading.


As for the exceptional performance of the Cascade, I defer to the design: it can handle the hot spots of the CPU die much better than any other block. The real puzzler is the magnitude of any kind of hot spot (if my theory is correct): I thought that the IHS's purpose was also to smooth out these hot spots.

[Cathar]

Originally posted by bigben2k
As for the exceptional performance of the Cascade, I defer to the design: it can handle the hot spots of the CPU die much better than any other block. The real puzzler is the magnitude of any kind of hot spot (if my theory is correct): I thought that the IHS's purpose was also to smooth out these hot spots.

Yes, the IHS smooths out hot-spots to a small degree, but it is still fairly thin and lateral spread is not that great, as you say.

Definitely something that warrants further investigation though.

[joemac]

Maybe the reasons the temperatures are so far off on an Intel CPU is due to Intel wanting the user to know the case temperature and not the die temperature. The case being the I.H.S. I am not sure but maybe the sensor used by motherboards to display temperatures is not in the die but on the outside measuring the air temp in the I.H.S.

[bigben2k]

Investigating that sounds like an insanely complicated idea: I can just picture each jet's output being redirected to individual tubes, for a temp measurement!


joemac: I would bet cold hard cash that Intel would go out of their way to hide a temp reading of a hot spot! If the real temp is off by as much as 40 degrees, that diode would have to be pretty far off from the center of the die indeed.

[Cathar]

Originally posted by joemac
Maybe the reasons the temperatures are so far off on an Intel CPU is due to Intel wanting the user to know the case temperature and not the die temperature. The case being the I.H.S. I am not sure but maybe the sensor used by motherboards to display temperatures is not in the die but on the outside measuring the air temp in the I.H.S.

The P4 diode that is used to measure the P4's temperature is located on-die, but it is off to one corner, away from the major heat producing regions of the CPU. I can't remember where I saw the picture now, but the diode is basically sitting by itself in a bit of a dead-zone with not much around it. The P4 die does have some small "gaps" due to the block layout nature of the functional units not all lining up happily all the time, and the diode sits in the middle of one of these areas, with basically no real heat-producing bits near it. It seems to be more of a measure, in the way in which it is located and implemented, of the IHS temperature in that area, and the temperature as a result of heat from hotter sections of the CPU conducting laterally through the CPU die. By itself, it is a rather poor measure of how hot the die can actually get (as indicated by the XBitLabs tests).

Found a link to the XbitLabs article here:

http://www.xbitlabs.com/articles/cpu/print/p4-temp.html

The three most relevent quotes from it are:

In order to save the CPU from damages in case of such breakdowns, the second thermal diode built into the CPU keeps track of another CPU temperature value. When this value is notched, it doesn't "slow down" the CPU anymore, but sends THERMTRIP# signal for the system to shut down.

For your information: the temperature when THERMTRIP# signal is sent equals about 135oC, according to Intel.

So all we could do, was to turn off the CPU cooler. After that, the CPU temperature rose to 94oC in less than one minute and the system shut down

So basically the second hidden diode is monitoring the peak CPU temperature, and shuts the system down when it hits 135C, yet the motherboard visible temperature diode is only reporting 94C when the system shuts down.

[winewood]

It sounds like Intel just took a step backwards. Sounds like change for the sake of change.

[bigben2k]

So now we're back to the puzzle: what's the temperature of the P4?

If there's a 39 deg C differential between the hot spot and what we can assume is a cold spot, and given that that variation probably changes with the heatload...

Puzzling!

[joemac]

I supposed that we could add 39 – 41 C to any reading that we get from the on board sensor that Intel does want us to read via the motherboard. This method is not uncommon in other fields and this seem to make things work out nicely. E.g our MB say temp is 96 c but we trip the THERMTRIP# signal so we can say our temp (96c) + (39c) = 135c and we get system off