"If the heat-die temperature were being monitored as well, then the TTV would be representative of CPU temperature, and would therefore be more suitable."
this is nonsense; apart from having an additional datum, what changed to then make the heat source acceptable ?
treat it as a black box, you know the heat input and the IHS (near) surface temp

not questioning the relevance of the source size, and its effects are shown in the very different wbs - the MCW6000 and the Storm
now there is an additional wb and all anyone can do is wring their hands about how to understand / interpret the numbers
- of course with the base assumption that the mfgr is lying

I am unable to predict the 'accuracy' of the Apogee curve as it is not 'mine'; but if Swiftech has not made fools of themselves, . . . .

"The wb is being manufactured to provide low temperature readings on a flawed testbed by exploiting the very same flaws that were observed to give erroneously low results. The data is the result of a system error."

how can the "flawed testbed" yield acceptable results for the MCW6000 and Storm, yet be unfit to measure the Apogee ?
did you compare the MCW50 and MCW55 data ? (same setup), so now you have more data sets
Cathar; you got a MCW55, how did it compare to the Storm ?

there are 2 testing people here telling everyone that an IHS temp is useful and the response is yap yap yap
and the same re testing with an IHS and there is more yap yap yap

should we split this into those popping the IHS and want data for bare CPUs ?
the other group uses CPU as packaged and wants data for the real applications ?

Cathar
I have no idea where this will land but if your theory will not accommodate the results, it is wrong
and you can resolve this yourself by testing the MCW55 you have

Bill TBH, I have been suspicious of the data ever since the results for the 55 came out. NOt that it is bogus, just that something is off. Then when I researched the TTV, it started to make sense. The TTV is not intended for the use to which Swiftech is using it.

Because the Apogee base is flexing and the Storm and MCW6000 bases are not? Pretty sure that is the argument.

Amended Model in Post 16
Now uses real dimensions.
Ta Lee

Edit1:
A note on predictions:
The predictions in Post 16 refer to "(C/W)average".
My position on TTV interpretation remains the same as posted at OC :-

Wow Les, even though just a simulation, is showing quite different results from Swiftech's, I suspect further testing will as well.

It is only a model.
That have previously had some good agreement with data means little.
There is every possibility it has been luck and/or error cancellation.
Blunders have a habit of canceling in this game.

"The TTV is not intended for the use to which Swiftech is using it."
for sure, but it is still a source which can be characterized
try considering data rather than listing all those things not known

the MCW50 and MCW55
was a difference shown ? yes
difference in bp stiffness - none

the MCW6000 and Storm
was a difference shown ? yes
difference in bp stiffness - low (?)

the MCW55 and Storm
was a difference shown ? yes
difference in bp stiffness - low (?)

the MCW6000 and Apogee
was a difference shown ? yes
difference in bp stiffness - high

the Storm and Apogee
was a difference shown ? yes
difference in bp stiffness - high

the MCW55 and Apogee
was a difference shown ? yes
difference in bp stiffness - high

a cynic might observe that reduced conduction losses from a thinner bp are sufficient for the above

you guys are trying to cherry-pick the data you consider (christ we're rooting for models no less)

Sulks. worked hard on the models.
Unfortunately that does not make them "good"

Bill, I understand your argument and your point of view, really. Not 'rooting' for anything. Like I said, if the Apogee performs as claimed, that's great. Everything that has been brought up re the TTV and flexing etc just gets dismissed by you and Roscal. If 2 or 3 independent tests show completely different data, what then? I know we all hate 'what if's' but will this not leave the consumer terribly confused? It certainly won't make Swiftech look good, or their testbed. Guess we need to wait and see.

the 'problem' is the MCW55 testing so much better than the 40, and then comparing it to the Storm
no flex issue to distort thinking

jk Les

Need to just let further testing take it's course.

Re: MCW55, the MCW55 is a little bit special. It has a raised base-plate plateau that is ~27x27mm in size, in accordance with fitting on GPU's that have shims installed.

Am pretty sure that heatsinks with that sort of geometry characteristics were not part of the TTV geometrical loading design. :shrug:

Who knows? Further testing will reveal. I think the points have been raised and the horse is flogged near to death now.

not being contentious, but being this far into it . . .
(and since I do know)

the pod on the MCW50/55 is ~2.89cm sq, it can be set on the IHS edges - as it was tested so
no flex in that data, worth considering if the TTV is being called a "flawed testbed"

EDIT
too small for the AMD IHS

I await independent tests of both Apogee and MCW55.

Incidentally Bill, since the MCW55 would primarily (solely?) be used on bare-die GPU dies, then why was only TTV/IHS data supplied? I don't really expect you to answer that question though, it's more rhetorical...

a TTV is a heat source
a wb bp cannot tell the difference between a copper slug and an IHS

do you guys think a die temp is known ? or necessary ?
-> the goal is the device thermal resistance, not that of the IHS
in all cases Swiftech is now describing the device thermal resistance

a fascinating question, elegantly phrased

implicitly you are suggesting that only bare silicon can emulate a silicon heat source, ?
or is it a difference in the variability of the flux density that the TTV does not replicate ?

please indicate for us all the proper heat source for GPU wb testing, I would like to get it right if I test another wb

I would say that it is the only thing of importance.

Perhaps this is the exact point where the overclocker and the thermal engineer differ. The thermal engineer is concerned with assessing the device's thermal characteristics in broad terms, in this instance the IHS surface temp. The overclocker only cares how well the thing that directly affects the ability to overclock is being cooled, being the temperature of the CPU die. There is a direct and immediate relationship between the peak CPU die temperature and the achievable overclock. A broad "smoothed out" IHS surface temperature assessment does not provide that information.

Now people may very well argue that 0.5-1.0C means SFA, but I tend to disagree in a world where performance is balanced against environmental considerations such as noise. That 0.5C gain may be "used" to lower noise levels, and so on. This is not directed at you Bill, but to those who argue that small differences mean little.

When talking about Swiftech's results think we should be considering "(C/W)local"
Think the 1x1mm die predictions are more apt for TTV data

I rarely post in these types of threads, well, because I have no background for it.
However, it seems to me that the conditions in dispute could be easily satisfied by using a TIM with a known thermal resistance value, like those pads Shin-Etsu makes. The construct a heat source thusly. Make a heat die the size of the actual core on an A64 or P4 or whatever, then apply pad, then attach a fabricated heat spreader to this assembly and place another pad on top of it, then attach waterblock. Time consuming and expensive as you would need to re-apply pads between tests (maybe they would do for a while, I don't know). Then extrapolate data based upon known thermal resistance of TIM.
Forgive me if stupid, I tried :)

But, Cathar, isn't the sub-IHS temperature directly proportional to the IHS temperature? The manner of testing involving the temperature above the IHS gives us a relative value, not an absolute one, but all we need is a relative one so we can choose the best block to get a better temperature both above and below the IHS.

As I read this thread and the discussion its turned into, I can't help but think....

If the IHS temp is 'important', why isn't there a IHS temp sensor on every motherboard?

As an average user and overclocker, I never know what the IHS temp really is, at ANY time. I could really care less about the IHS temp.

What I do get to see is die temp, a reference number at best. But the only CPU temp as a user I get to see.

If you give temps for the IHS for reference, you might as well sell me a car and tell me how fast it goes down hill. A Ford Focus can do 0-60 in 5.0 flat going down hill at the right grade.

Waterblocks are for cooling CPU's right?

:shrug:

The IHS temperature is NOT important to overclocking, which is what Cathar is saying.

I believe that the IHS temperature is used in testing because it's an easily acquired number - you can't drill a hole in a CPU, but you can in a metal plate above it. IHS based testing will not indicate what the CPU temperature below is, but that's not the goal. The goal is to see whether Block A will produce a warmer or cooler CPU than Block B. Measuring above the IHS also removes the IHS-CPU TIM joint variable, so you don't have to worry about that degrading.

But it is usable as a method for establishing heat exchanger performance.

However, as with any method the relationship to normal reality needs to be understood.
I'm trying to model this kind of behaviour.
There are differences between blocks on the TTV (and all test testups) that don't exist in reality. This is true with or without the IHS
Some modelling which I'm too fatigued to explain at this point.
Not visible in the gradient chart but there is a 0.02° difference between the two blocks in the two different scenarios at the die core, meaning that the test setup is itself dependent on the block it is testing.
This is exacerbated by TIM variations etc. which I have not modelled at this point. (too complex in a hurry) and even more significant with thin vs thick bases, concentrated cooling regions bla bla

Any test method is inherently flawed unless we understand it.


I am almost typing in my sleep here, forgive the incoherence.

Does anyone know if it was testing with 3/8" barbs or 1/2" barbs? I'm guessing 3/8" because it was compared to the 6000, but I'm still wondering.

http://www.swiftnets.com/assets/imag...%20vs%20FR.GIF

says it is compared with mcw-6002

the test data in question has nothing to do with the overclockability of a cpu. it demonstrates the components' thermal resistance. thermal resistance is our standard of measuring thermal component performance, no? the goal of testers is to have accurate results for c/w, right? i know cathar takes great time in explaining a lot of things to the rest of us, but i still can't understand that because the system is not measuring die temp it results in less accurate results for c/w.

Did anyone read my second paragraph? :(