Yeehaaa! E3110 TJ is 95 not 100 ! I`m happy:D
Printable View
Yeehaaa! E3110 TJ is 95 not 100 ! I`m happy:D
Quote:
Originally Posted by WaterFlex
that means you have less headroom. ehehe
webb, rge, gurus, everyone,
I have a question - which may already be answered in this thread. Intel says Tcase (thermal spec) is 72.4C (C0) or 74.1C (E0) for E8400s. What does this mean as far as determining a maximum safe temperature for the cores?
I still cannot understand the relationship between intel's 72.4/74.1C limitations and the core temperatures measured by realtemp & coretemp.
Intel® Core™2 Duo Desktop Processor E8400
Processor Specifications:
sSpec Number:SLAPL
CPU Speed:3 GHz
PCG:06
Bus Speed:1333 MHz
Bus/Core Ratio:9
L2 Cache Size:6 MB
L2 Cache Speed:3 GHz
Package Type:LGA775
Manufacturing Technology:45 nm
Core Stepping:C0
CPUID String:10676h
Thermal Design Power:65W
Thermal Specification:72.4°C
VID Voltage Range:0.85V – 1.3625V
Intel® Core™2 Duo Desktop Processor E8400
Processor Specifications:
sSpec Number:SLB9J
CPU Speed:3 GHz
PCG:06
Bus Speed:1333 MHz
Bus/Core Ratio:9
L2 Cache Size:6 MB
L2 Cache Speed:3 GHz
Package Type:LGA775
Manufacturing Technology:45 nm
Core Stepping:E0
CPUID String:1067Ah
Thermal Design Power:65W
Thermal Specification:74.1°C
VID Voltage Range:0.85V – 1.3625V
Edit: Ahh I may have found my answer. Looks like intel assumes that when the top center of the E0 E8400's IHS reaches a temperature of 74.1°C, the temperature of the cores at that moment must be somewhere between 95C and 100C. I say this because of the mobile processors not having any IHS and Tcase being equal to Tjunction. When TM2 trips or activates prochot on the mobile core2duos, tcase max has been reached, and ironically it's the same as tjmax. So they have to be assuming that cpus with the IHS on them reach tjmax & tcase max simultaneously such as: 74.1C/100C. Correct?
Quote from intel:
"The thermal specification shown is the maximum case temperature at the maximum Thermal Design Power (TDP) value for that processor. It is measured at the geometric center on the topside of the processor integrated heat spreader. For processors without integrated heat spreaders such as mobile processors, the thermal specification is referred to as the junction temperature (Tj). The maximum junction temperature is defined by an activation of the processor Intel® Thermal Monitor. The Intel Thermal Monitor’s automatic mode is used to indicate that the maximum TJ has been reached."
jaredpace,
I might have an answer to that a few hours from now after I finish drilling a small hole in the middle of intel heatsink, so I can check core, cpu temps versus tcase temps at idle and load. etching my cpu will not work, as I have to keep the surface probe perpendicular, so flat surface is against flat surface....so straight through the heatsink, fan and anything else that gets in way of my drill....btw...drilling through copper is a pain, may have to get sharper drill bit. It might be 1-2 degrees of error, but i have learned the IHS is such a good heat spreader that temps wont get more than about 1C difference across large area of it.
i bet you see something like this at maximum temps:
IHS thermocouple: ~73°C
Core temperatures: 95°C~100°C
Good news at least is that Nehalem should have an uniform DTS accuracy across temperature range.
looking forward to your results rge!
bingo!Quote:
Originally Posted by jaredpace
after going through about 80 pics, different temps and notes best guess for core to ambient gradient.
1.1vcore, 6x300, stock cooler-------------------same settings but water+PA120.3
ambient 24C------------------------------------------------ambient 24C
IHS 30C----------------------------------------------------IHS should be 27C (b/c cpu set to track IHS at idle)
CPU diode 30C (reads few C too low at idle)--------------CPU diode reading 27C (set track IHS at idle not load)
core temp 34-35C (best guess)---------------------------core temp 30-31C (best guess)
Using water or top air cooling ~6-7C difference between core temp and ambient temp
when undervolted, underclocked idle. It can not be less than 5C, can not be more than 8C.
IHS is 3 C above ambient. Gradient from IHS to core estimated 3 ways. One is by checking temps at same settings in 4 diff ambients,
then plotting error backwards came out to 30.5C, going by 2C error at higher temps came out to 31C, and using known gradient of 4C on pentium and 4-5C heatsink off E8400 and knowing should be less with heatsink on 30-31C.
Using water/PA120.3 stock 6x333 (speedstep enabled), stock volts 1.2v core, idle, core temp is ~7-8C above ambient.
Using stock intel cooling, undervolted, underclocked likely 10-11C gradient from ambient to core, as IHS is 6C above ambient and core another 4-5C (at least) above IHS, gradient cant be less than 9, cant be more than 12C.
Using stock intel cooling, stock clock, stock volts 1.2vcore, gradient from ambient to core about 14C. (the higher the voltage you go, the more benefit you see from better cooling)
when choosing cpu temp calibration for E8400, apparently need to decide:
1) do you want your cpu temp to report the temp where the cpu diode is located, between cores, and report a few C cooler than die temps on load
or 2) do you want your cpu temp to approximate IHS temp and report 14C cooler than die temps on orthos load or up to 26-28C cooler temps on max linpack load (assuming stock settings, stock intel cooling on (E8400) ie....tjmax 100C - tcasemax 72C....ie it is not possible to actually track true IHS temps with cpu diode, because it is located in wrong place and calibration would need to be adjusted by 20C going from idle to max load. So do choice 1, choice 2 is not possible....it can be calibrated to mimic IHS idle OR IHS orthos load OR IHS linpack load, but one of the three will be accurate the other two would be wildly off.
In previous intel docs and even in recent slides, intel states DTS is calibrated such that throttling occurs just above tcase max...ie when cpu at full load that produces near 100C tjmax temps, at intel worst case testing parameters, IHS temp should be just over 72C...assuming intel testing parameters, stock clock, stock cooling, intel loading program etc. Who knows the exact relationship when OCing, I could not really test it as already at 83C with linpack on intel cooler.
Interestingly the GB bios calibrates cpu temp 7C lower than what I have it set to (bios F7)...so cpu temp reads -7C from true IHS at idle, +7C over true IHS at orthos load, and ~+20C too high at linpack load....they split the difference between idle and orthos load, which is probably the best you can do if trying to mimic IHS.
In the pics, prior to drilling a hole in intel stock cooler, I tried with native fan, stock settings, idle and load. I then placed a box fan to hit intel heatsink and removed intel fan and put box fan on a speed to replicate same temps, since I could not use fan with thermocouple attached. After drilling hole in heatsink, I got roughly same temps within 1-2C...so one little hole did not affect things too much.
Also in last pic, note after load is off, immediately IHS temp is within 8C of core temp, and tracked within 7-8C of core temps back down several degrees, suggesting 5-6C difference between IHS temp and true core temp at idle at stock settings with speedstep on using crappy intel cooler...can not be more than 8C and core temp is reading 2-3C too high at that point, so should be 5-6C.
so at idle, gradient between tcase & tjunction is ~ 2 to 5 Celcius? And as you go into loaded temperatures, the cpu maxes out at 72C tcase & 100C tjunction and the gradient increases to ~ 27C.
Temp #1 COOL Idle (sensors probably stuck - evident by testing outside)
Tcase:29C
Tjunction:30C
Cpu Temp:35C or 41C(wrong)
Tcase/Tjunction Gradient:~1C
Tcase/Cputemp Gradient:5C or 11C(wrong)
Temp #2 MILD temps
Tcase:47.4C
Tjunction:65C
Cpu Temp:~61C
Tcase/Tjunction Gradient:~18C
Tcase/Cputemp Gradient:~4C
Temp #3 HOT~84C coretemp
Tcase:56.7C
Tjunction:84C
Cpu Temp:~80C
Tcase/Tjunction Gradient:~27C
Tcase/Cputemp Gradient:~4C
Temp #4 HOT (Theoretical Max)
Tcase:~72C
Tjunction:~100C
Cpu Temp:~94C?
Tcase/Tjunction Gradient:~27C? (If tests are correct)
Tcase/Cputemp Gradient:~6C?
Temp #5 Cool down to idle
Tcase:50.2C
Tjunction:58C
Cpu Temp:55C?
Tcase/Tjunction Gradient:~8C
Tcase/Cputemp Gradient:~5C?
Interesting. This means that when you're running your E8400 at 80C core temperature you're nowhere near intels Tcase maximum or 72.4 or 74.1C. You're probably closer to 58-60C Tcase.
Thanks for the tests Rge!
one last pic showing IR vs thermocouple...turning computer on then off, both showed 44C, then tracked down within 1C of each other to both reading 37 in pic...took some pics where both read ~83C...but did not come out.
so your IR thermometer is/was correct from the start and the thermocouple is not actually needed? Interesting! Am I correct in guessing that the Tcase to Tjunction gradient is increasing as the junction temperature rises from 40C --> 90C?
For example:p::
Tcase temp: 30 40 45 50 55 60 65 70 74
Tjunct temp: 31 42 50 58 66 76 84 95 100
Gradient ~: .01...2...5...8..11.16.19..25.27
Is this a close scale?
yes, assuming full load, stock cooler, stock vcore, stock clock, exact intel loading program, and reasonable ambients. Intel states under those conditions, throttling is set to occur (tjmax reached) just as tcase is exceeded. Also depending on type loading program that gradient can vary significantly even at same temp, which is why intel goes on to say in docs that the relationship is not guaranteed.Quote:
Originally Posted by jaredpace
And of course if you cheat and remove cooler to get temps that high at idle, then relationship no longer true and tcase = tjmax - 5C. When overclocking and different cooling, I am sure significant gradient exists...but likely different in some ways...just dont know how much.
Also in your other post, under Temp #1 you switched temps on cpu and junction, also my cpu temp reads 2-3 too low at idle temps, and I think you meant to say Tjunction/cpu gradient instead of Tcase/cpu gradient at end of each...but thanks for summarizing, saved me some typing:D
It's me again with yet another insane idea. :)
First of all : rge, you rock! :clap:
Now back to the idea. As we know Intel might mean different things with their new Target TJ value. It seems obvious that those 70C & 80C for 65nm mean something different than 95-100C for 45nm despite being given the same name. But, as rge has proved, at DTS=0 we are supposed to get IHS temps very close or equal to those listed in thermal specification (72-74C for 45nm CPUs). But personally I cannot believe in a gradient of 27C (or maybe even more, as it will most likely increase with higher temps) between core temps and IHS. The previous P4 testing is a good proof to that. On a 65nm CPU this gradient would've been much lesser and much more reasonable, should we decide to use Intel's TJ Target value of 70C for B2 or 80C for G0 (15-20C offset from guessed TJmax used earlier) and IHS values taken from processorfinder of 60.1C and 72C respectively. So maybe these new "official" numbers for 65nm aren't that wrong? Thermal specification for 45nm is very close to that of 65nm G0 stepping (72-74 vs 72). If we (hypothetically) assume TJmax=80C (same 20C offset) for 45nm CPUs then we'd see only 7C gradient in rge's testing and 6-8C gradient at DTS=0 according to Intel's specs (72-74 IHS temps and this hypothetical 80C Tjmax). The abnormally low core temperatures in this case at idle & medium load could be explained by sensors' inaccuracy (slope error) while high load core temps would be more accurate & close to IHS temps.
Sorry for my English, I'm not sure I expressed everything the way I meant to.:D
I am now positive there is a 27C gradient from tcasemax to tjmax at full load (high TDP), measuring at true IHS versus core. Note this has nothing to do with the small few C gradient from DTS die temps to cpu diode (between cores still in die with very high thermal conductance). But to see this gradient from IHS to core temps you have to be at full load (high TDP) with a heatsink. A large gradient was duplicated at university testing better than mine on Pentium northwood.Quote:
Originally Posted by Dua|ist
If I remove heatsink, at idle, low volts, (LOW TDP) when tjmax of 100C is reached IHS thermocouple reads 95C, because there is no load (minimal TDP) to drive a gradient, so no gradient exists other than minimal across tim1.
Putting heatsink on to cool IHS, placing a load to drive the gradient and the higher the TDP, the higher the gradient given same type of load and other parameters, and you can measure a 27C gradient from IHS to core temp at max TDP. The P4 has same gradient if you test with heatsink on...I tested with heatsink off.
Intel states even in recent slide presentation
"DTS calibration point adjusted higher than target TJUNCTION
– Minimizes potential for PROCHOT# activation below TCASEMAX"
So intel cpu under stock conditions, under max TDP load is designed for throttling DTS=0 at just above tcasemax....to self protect cpu, assuming you do not cheat and raise temps at low TDP by removing heatsink.
If you use tjmax 80 for E8400, than you would have trouble explaining why when IHS temp reads 94C, distance to tjmax is 1 and it is not throttling.... so it is not possible for E8400 tjmax to be less than 95C, nor is it possible to have 100 tjmax with more than 1C DTS sensor offset (effectively same thing as lowering tjmax). Given 4-5C gradient at idle, it has to be 99 to 100C.
That's true.Quote:
Originally Posted by rge
Then maybe DTS data depends on TDP too? And DTS reports accurate temps only when testing with a cooler, not without & undervolted, underclocked? In that case I would still like TJtarget = 80C.
Under stock conditions we're supposed to get TCasemax at target TJunction (DTS=0). Your testing proved that. At DTS=0 it starts throttling and tries to keep the temperature at or below target TJunction (and TCasemax, since they're equal at stock conditions).
Some Intel datasheet (found the quote here) says:
"...In the event of a catastrophic cooling failure, the processor will
automatically shut down when the silicon has reached a
temperature approximately 20 °C above the maximum TC..." Or above target TJunction which is the same.
Once again those 20C...
What if:
- PROCHOT# is triggered at TJtarget which as we know is DTS=0 (throttling starts)
- THERMTRIP# is triggered at TJmax which is... DTS=-20 and the absolute maximum temp (CPU shuts itself down)
- the 100C value for 45nm processors in the August pdf is the TJmax value (it was even called so at that time), and not the TJtarget
- the 80C value for G0 65nm processors (with same TCasemax temps as for 45nm ones!) is the TJtarget value and TJmax is the same 80+20=100C but occuring not at DTS=0 but at DTS=-20
- the target TJunction in October pdf means a) a "real" TJtarget for 65nm CPUs b) the good old yet misunderstood TJmax for 45nm CPUs (while "real" TJtarget being the same 80C). Maybe they didn't dare to change it since they already published 100C before in August (then why not use TJmax for other CPUs? - still a mystery)
For me it's the only way of explaining why Target TJunction values for 65nm and 45nm processors differ so much when their TCasemax temps are equal.
P. S. It's only my version. You guys must know much more than I do, so please forgive me this nonsense I wrote. :)
The temp sensor is going to function and report temps the same whether heat sink is on or off, TDP will not affect DTS functioning. My E8400 shuts off at around 115-118C tcase, it throttles at 95C tcase...so again not possible for tj 80C on e8400.
If you are having trouble believing 28C gradients exist over such a small space...read this research paper of pentium northwood....look at slide 22. Gradients exist that high on E8400 as well, but primarily because of more optimal sensor placement of die sensors and diode sensors and copper banding in silicon die, die shrinkage, etc the gradient will not be seen from dts to cpu diode, but from those two diodes to IHS.
http://www.ee.ucr.edu/~stan/papers/todaes07_softsen.pdf
LINKS TO YOUTUBE VIDEOS BELOW SHOWING GRADIENTS
According to intel Tcase formula
Tjmax-Tcasemax gradient = theta(jt)*TDP
The higher the TDP the higher the gradient from Tj to Tcase. TDP is primarily dependent on load but also voltage, however core temps in themselves dont alter the gradient...just that under normal circumstance temps are only high at high loads. See formula in pic below.
Though you will never see this gradient, unless you measure tcase with thermocouple...as gradient from core to cpu temp is not more than 5C.
At 1V, IDLE ie LOW TDP, 2x266, there is a 5C gradient from tjmax to tcase whether temp is 60C or up to 100 C (no heatsink). ie, at 100C core IHS = 95C... or at 50C core IHS=45c, etc. (at lower core temps gradient is still 5C, but reads 10C from DTS reading 5C too high in idle range)
At 1.25v, IDLE, 9x333, there is a 7C gradient from tjmax to tcase regardless of temp, 60C to 100C, (slightly higher TDP as higher vcore)
ie at 100C tjunction IHS=93...or at 50C tjunction, IHS=43C, etc (at lower temps gradient still 7C reads higher from inaccurate DTS in low range)
At 1.4v, idle 9x333, there is a gradient from tjmax to tcase of ~10C from 60C to 100C (again higher idle TDP from higher vcore)
ie at 100C tjunction, tcase is 90-91, etc
Stock cooler, stock 9x333, 1.25 vcore
idle, gradient core to IHS = 6-7C
orthos load 14-16C
linpack load 22-24C
load at higher volts increases gradient, better cooling decreases gradient.
Video 1 demonstrates high temps with low TDP (IDLE) using 1.37 vcore (so temps would get higher) illustrates still only 9-10C whether temps are in low range or high range...only showed high range, point being gradient is TDP dependent, not temp dependent.
http://www.youtube.com/user/rge42
Video 2 demonstrates first intel cooler w/box fan, stock vcore 1.2, stock 9x333, idle (low) TDP, with 6-7C gradient (gradient reads 1-2C too high as 1-2C DTS error in that range. Then linpack load demonstrating 22-23C core to IHS gradient, then slightly higher gradient as decrease fan speed and lessen cooling ability.
http://www.youtube.com/watch?v=q7ua2FFByfI
I am done with testing for awhile...2:30 am...need to sleep. If anyone wants to duplicate experiment, just get thermocouple calibrated for surface temps (calibrated 4C higher per eng i borrowed from). drill small notch dead center in IHS very shallow depth to just seat tip of thermocouple, put small amount of thermal grease on tip...but to use second method to guage temps, mine were within 1C of IR temps, I duplicated approximate depth for tcase measurement per intel...though the notch did not alter temps but maybe .5 to 1C, it did however make them very reproducible within 1-2C.
This is all very interesting theoretical stuff, but I'm not seeing what relevance it has to making RealTemp, which only reads the DTS info from the chip and doesn't read temps at all, more accurate in reporting the actual chip temperature. Other than at low-end calibration, how does any of this information or speculation help? Is it changing the top point of the graph in any meaningful way?
I thought the only practical value of note was the TjMax one, which is what RealTemp uses to convert the DTS to a temp reading. How is Tcase or anything else useful? Once I've put a heatsink on my chip, I don't give a flying f* what temperature the IHS or the heatsink is at, as long as it's keeping the processor cool... :shrug:
I'm just wondering how this information will help us get a better value for TjMax? Short of us all drilling holes in our CPUs to calibrate each one accurately, I thought we were all stuck with the +/-20 degree inaccuracy inherent in these sensors and in the original per-chip Intel calibration. To a casual onlooker, it seems we are pretty much back to square one right now, to what unclewebb was saying about a year ago in threads here, that the only useful info is the DTS reported distance from TjMax and that as long as you're not throttling you shouldn't really care too much. :ROTF:
Kevin (Unclewebb) had asked me if I could find a way to measure the IHS temp via a thermocouple for the purpose of gradients and resting idle temps, which is useful to determine idle temp calibration as well as trying to figure out tjunction diff between 65nm and 45nm, hence get accurate load temps as well. Also understanding the gradients helps with understanding Tcase specs. If all you are interested in is distance to tjmax, then yes this information is useless. But if it upsets you in some way for those of us interested in absolute temps, why not just ignore it, instead of needing to post you dont give a "flying f" about it?
Well Intel lets you know that you can't get the chip hotter than ~ 73C Tcase, but the software only measures DTS (Tjunction). The purpose is to find the exact relationship between Tcase and Tjunction (the gradient).Quote:
Originally Posted by IanB
You know you can't run your E8xxx/E7xxx hotter than Tjunction = 100C, but how do you know your Tcase temperature at that point?
This is the reason for measuring the temperature on the IHS.:up:
What happens to IHS temp if you leave the linpack testing going for about 15 mins? does it catch up to the Realtemp temps displayed on the screen?Quote:
Originally Posted by rge
Sweet testing Rge!!:up:
Thanks...IHS temp has a few seconds lag for heating up since it is being cooled, but the gradient then stays constant ~20-24C (expect when linpack drops off between intermittent loads). If you watch as IHS is climbing after initial several seconds of equilibration.. .1, .2 as soon as it gets 1C hotter, realtemp core gets 1C hotter...so if temps start out tcase 55, core 77...when tcase gradually increases to a steady state, case temp was 65 and core 87 with fan on medium. I have several hours of testing and couple hours of video ...most would make you puke to watch from motion sickness....had to learn how to video. Also I turned fan speed down at end to show gradient increases couple degrees with worse cooling.Quote:
Originally Posted by jaredpace
Yes, thanks rge. Your testing is detailed and useful as always. :clap: The info on Northwood temp calculations was also very educational. :yepp:
I must admit you beat me. But then we just have to admit that Target TJ values for 65nm are plain wrong... Or Intel means something else with these new numbers. :shrug:
P.S. The thermal specification formula is quite interesting too. It could explain why newer steppings have higher TCasemax temps (relative to their TJunction temps). If the psi (or theta?) value is a constant, then due to lower power consumption (TDP) of the new stepping we get less difference (gradient) between TCasemax & TJunction. This makes me think that TCasemax might be some kind of "secondary" value, calculated (or measured) based on TJunction temperatures, as it isn't a whole number.
So, in conclusion, the maximum core temperatures for C0 and E0 E8xxx series chips is......
:p:
Well actually it was yours and others questioning that got me to do the videos and more testing, which I learned something from....so thank you. Also I think vids are helpful in that unless you see it yourself you always wonder.Quote:
Originally Posted by Dua|ist
Jaredpace...the max gradient you will likely encounter is 26C, intel tests this under worst case conditions with stock cooling, hence if you stay 26C from tjmax, you are likely always within tcase spec (if you overclock with stock cooler you increase it, but offset it by better cooling). Once you are less than 26C from tjmax, you may or may not be in spec, depending on the loading program, hence intel states the gradient is variable and can not be used to predict tcase. But as Unclewebb has pointed out, under those situations where you are pushing the limits, to get stability you will probably need to maintain such a distance from tjmax anyways. Another way to look at it if your core is 74C...you know your Tcase is significantly lower...and at that point the rule of every 10-15C you drop your temp, you double life of your component becomes more important especially when overclocking with high voltage.
One interesting side note from all the testing, I am now sure of 6-7C (can not be more than 8 or less than 5) over ambient for high end water or air cooling at low volts, idle, speedstep on or 6x333. I can set cpu temp to exactly track IHS reading as long as I stay at idle, same tdp. No question the IHS is 3C over ambient on water and 6C over ambient with intel stock cooling. The gradient from core to IHS is max 5C at those conditions, but I am convinced it drops by 20% with intel heatsink on and high box fan speed, and more with high end cooling (max 50% decrease) . It would not surprise me if the entire gradient were halved comparing water to intel stock cooling where core is ~10-12C above ambient at those conditions with stock cooling.
Thanks rge. I've run out of thumbs up for all of your testing. It helps everyone understand the gradients that exist and goes further than my testing that was always done at idle without a heatsink installed.
I still read in forums about users running Prime95 with reported core temperatures of ~60C but their heatsinks don't even feel warm. Now we know why. The heat dissipates rapidly from the source when a heatsink is installed.
It confirms TjMax=100C is correct for the E8400 and that the RealTemp calibration method at low MHz / low core voltage, is valid for users that want more accurate core temperatures. It might need to be adjusted by a degree or two based on your recent testing so could you create a small chart showing what temperatures a user should aim for when calibrating? Intel OEM, aftermarket air and water. I might have some fun with my drill this week to see what I can learn. :)
I'm thinking about getting an e8400 and running it at greater than 1.45v-1.50v actual and/or higher than 80C load. Just to see what will happen, since I really haven't heard of anyone doing this and reporting back. I have a feeling it will just degrade the cpu over time making it require more volts to achieve the same megahertz, while producing more heat in the process. But in the meantime, I could probably run 4.8ghz 24/7! :ROTF:
Thanks, I enjoyed all the testing as I know you do...great educational hobby. As for calibrating idle temps, after all my testing I was looking for a reference and saw one of your old posts that already correctly estimate idle temps for high end cooling.:D. But I can list what I found for water, zalman, and intel stock.Quote:
Originally Posted by unclewebb
Interestingly, the gradient with intel stock cooler at low volts idle is ~10-11C. If you then turn a box fan on high (15inch fan at high rpms).. you lower temps and drop gradient 2C, more effective cooling compresses temp range and corresponding gradient becomes smaller...that is not exactly the way I imagined gradients before testing. And yep the gradient to the heatsink is huge.
To calibrate idle temps for core 2 duo: First set vcore 1.1V bios +/-~.03v and 6x333 mhz manually or leave speedstep enabled. Then set idle so it reads listed degrees above ambient for given cooling:
COOLING...............................IDLE DEGREES ABOVE AMBIENT
High end water...............................6C above ambient
High end air (true push/pull) ........6-7C
High end air (1fan).........................7C
Mid air (zalman 9500)....................8-9C depending on fan rpm
Intel stock cooler...........................10-11C
Need to use listed volts for calibrating, increasing volts significantly will widen the gap between better and worse cooling and alter the gradients.
Edit: I will have to leave quad estimating to you, i dont have one.
rge: Your testing confirms what I was thinking during some informal testing I did a couple of days ago.
#2395
Looks like the truth is somewhere in between. Your chart will provide users with a baseline when calibrating no matter what type of cooling they're using and I will include this info in the updated documentation with a link to what's been learned during testing.Quote:
I'm suspicious that my assumption that a well air cooled Core 2 Duo should run about 5C hotter than ambient at low MHz and low voltage might be too conservative. Maybe our calibration method at low volts / low MHz should be based on 10C.
For a Quad like my Q6600 - G0, I think I would add 2C to your numbers. Time for some more testing.
I've just started comparing power consumption to core temperatures which might help users with calibrating and checking for sticking sensors. Now that we have a baseline it will be easier coming up with answers about Quads, etc. based on power consumption.
By adjusting Clock Modulation in MSR 0x19A, you can also create a nice graph comparing core temperatures at different power levels while running a consistent stress program like Prime95 small FFTs. I'll include this option in the next RealTemp for testing purposes.
Anyone interested in checking this out can use my MSR program to set model specific register 0x19A like this for each core:
12.5% -> 0x12
25.0% -> 0x14
37.5% -> 0x16
50.0% -> 0x18
62.5% -> 0x1A
75.0% -> 0x1C
87.5% -> 0x1E
To return your processor to full power set MSR 0x19A to 0x02
The percentages aren't exact but if you step through different power levels while running Prime you should see your core temps go through different steps. If the temps don't change equally between cores then I think this new test should help confirm sticking sensor issues or maybe even slope error issues. It's a work in progress.
E6600 @ 2.7GHz
http://i176.photobucket.com/albums/w...PowerLevel.png
Core #0 was occasionally slower at changing temp than Core #1, but was always within 1C. Temps reported using RealTemp 2.79.8
EDIT: I suppose I should say what I used for loading the CPU ;) Prime95 small FFTs.
I didn't disparage your testing in any way, if you actually read what I wrote. I said I don't care what IHS temps are as long as the heatsink is working and keeping the processor inside acceptably cool, which is surely the situation for most of us. Thank you for twisting my words. :mad:Quote:
Originally Posted by rge
And have you never heard the phrase "devil's advocate"? I was asking what most casual readers will be wondering after that theoretical jargon and testing, which is how does it help improve our understanding of temps reported by the DTS, which is what this thread IS about (ie. RealTemp). If it improves the calibration possibilities, then explain how. It was a simple enough question. :shrug: Now it seems to have been answered. :up:
Now, the question is, can this be incorporated into Realtemp to make calibration even easier and foolproof for most users? For example, consider a calibration "wizard" that would check the processor is idling as specified, confirm the cooling spec and ask for an ambient temperature to be entered... and presto the setting is done without editing INI files and requiring user hunches (assuming sticky sensors are not detected). That's a practical result from this which is an achievable goal. ;)
Ian, did not mean to misconstrue your words, miscommunication happens all time on net as cant decipher tone, I meant no offense and none taken. Goal is to understand the slope error, idle temp range, and gradient from IHS to core to get accurate temps across the range, and I think it is very possible to do. And as Unclewebb stated, the same info will need to be applied to Nehalem as intel states the errors are still there just to a lesser degree. Also it is especially important for 65nm, since intel has not released the large offsets needed to be added to tj target to calculate accurate 65nm temps
Unclewebb...like the power consumption graph...will have to play around with that
I just got my E8600 10 mins ago, even if upgrading to nehalem in 4-6 months or sooner, I want a good backup computer, and my E8400 has had too much abuse.
My last test on E8400 will be drill rest way through to core,...so may be down few days. Only problem, I will have to recalibrate for surface reading since I cant drill a hole in core to put thermocouple tip in, like I did with IHS (at least wont try that until all other testing)...but I can get exact absolute gradient by apples to apples comparison from thermocouple coated in thermal paste touching flat core vs flat IHS, as the small error is constant. I can calibrate that error exactly with IR (just few C) and and then read absolute temps by subtracting known small error.
OK Uncleweb I need some clarification.
After Intel releases the TJ max of their processors I currently have a Q6600 what is the correct TJ Max that I have to set in RealTemp.? BTW I am using the Beta version.
Right now since I saw 90 thats what I set the TJ Max. my temps currently are 30 29 27 30 with ambient of 20.5 C. IS that correct? Did I made the correct change from 100 tj max to 90?
Ill appreciate clarification I really like RealTemp tool over Speedfan, Coretemp etc.
Thanks
pifive: There are two different versions of the Q6600:
Stepping B3 - CPUID 0x6F7 - TjMax = 90C
Stepping G0 - CPUID 0x6FB - TjMax = 100C
A program like CPU-z will show you what stepping you have and RealTemp will show you one of those two CPUIDs.
At the recent IDF, Intel has said that the TJ Target for these processors is 80C and 90C. To be honest, I'm not quite sure what that means or the relationship to TjMax.
My opinion is that for accurate core temperatures, you need to use a +10C offset from this Intel spec so the latest beta of RealTemp is still using 90C and 100C. Click on the Defaults button in the RealTemp Settings window and it will show you what your default TjMax is. Your reported temps look realistic to me but you would need to give me a lot more details about your case and cooling used and MHz and core voltage and........ Try doing the RealTemp calibration procedure as outlined in the docs.
IanB: Automatic calibration would be a wonderful thing but I don't think it's possible. There are just too many unknowns starting with the latest curve ball Intel threw at us at the recent IDF. I haven't quite figured out what TJ Target really means and I probably never will. Then there are sticking sensors, slope error and Intel calibration error at TjMax, both of unknown magnitudes, and etc., etc.
By the time I get an accurate Automatic Calibration feature finished, they'll be retiring Core i7. :)
randomizer: Nice graph. Maybe automatic calibration isn't as far off as I thought. It's pretty easy to see what your idle temps are going to be at the next step when load is 0%.
Scary thought isn't it? I believe I was hovering around 53C before I ran prime95 :eek:Quote:
Originally Posted by unclewebb
randomizer: What I found during testing is that if you leave MSR 0x19A set to 0x12 and then stop Prime95 your temps will drop down one more step and then while idle if you set MSR 0x19A back to the default 0x02, your temps will drop another degree or two. I think it lets your processor go into a slightly lower power state but don't quote me on that. With my Kill-a-Watt meter plugged in, power consumption drops a couple of watts.
Your graph shows that your sensors are working fine and aren't sticking. There's no way my E6400 - B2 is TjMax=70C like Intel has recommended but for your E6600, it looks possible. Did you ever do the low MHz / low voltage test? I'll go look back a few pages. I'd try TjMax = 70C or 75C and see how things look during this test. Now that rge has cleared up what the low end should look like and Intel has given us some guidance on what TjMax might be, maybe you can finally make some sense out of your sensors.
How do you like the ability to manipulate the power level your CPU is running at? Prime95 small FFTs is my fav for keeping the power level consistent. Anyone with sticking sensors that plots a graph like you did will end up with the lower part of the graph going horizontal but yours looks good. I plan to add power level adjustment into RealTemp for testing in the near future and then maybe have it test automatically and draw a nice graph like you showed us sometime in the future.
Used a flat head bit to drill through IHS to core (pic 1). Shiny part of the hole on left is top die, on right barely drilled into top of die/mold compound, not deep like it looks:D. Spent about 4 hours testing so far...may make vids this weekend if have time, have couple made, but not the interesting stuff.
The idle temps above in post 2429 are right on the mark.
The magnitude of the gradients is confirmed, their location I was wrong about. There is a significant layer of die/mold compound over the DTS core and cpu sensors, and the majority of the gradient (60-65%) occurs across that layer to top of die, the rest of the gradient occurs across IHS and tim1.
................................Sensor die temp.........thermocouple DIE temp............Thermocouple IHS temp
NO HEATSINK
IDLE 6x266, 1.1v-----100C (DTS=0)------------------97-98C----------------------------94-95C
LOAD 6x266, 1.1v-----77C-----------------------------70C--------------------------------65C
stock cooler
LOAD 9x333, 1.2V-----68C-----------------------------58C--------------------------------51-52
at higher volt setting to allow higher temp...load returns to idle, once again software sensor reads only few C higher than thermocouple to top of die, (2-3C gradient at idle low volts, confirmed by varying voltage and watching gradient changes).
The testing from the university (pic2 below or slide 22 link) http://www.ee.ucr.edu/~stan/papers/todaes07_softsen.pdf shows exactly the same thing regarding location of the gradients, despite testing a northwood. The only difference is the cpu diode in northwood with much larger die size better tracked IHS temp, whereas on 45nm the cpu diode better tracks core temp ?minus a few C.
The core and cpu sensors are close together on die on 45 and 65nm hence you see little gradient (5C max 65nm) from core to cpu sensor. You will not see core to core gradient for same reason plus there are multiple DTS sensors everywhere, only hottest reported, which makes gradients much less likely to be visible "horizontally".
This actually makes sense once you play around with it for awhile. You are actively cooling IHS, copper transmits heat instantaneously, hence relatively small gradient across IHS which has high conductivity close to cooling mechanism, but still gradient increases across the IHS with load as expected. The majority 60-65% of the gradient is without question through mold compound located over the die/cpu sensors and under the top of the die where thermocouple measures tem....just like pic in university shows, was with orthos anyways, but as the university pics show, the gradient location and magnitude can vary depending on loading program. The copper laden die/mold does have a high thermal conductivity around ~125 W/M*K, but still roughly 1/3 of that of copper 390 W/M*K, so top of die is well cooled via IHS compared to further into die.
Edit: also on weekend I will try to run an actual thermocouple die temp versus software core temp to get idea of slope error. But at idle, since half gradient is across IHS and half across mold and constant 5C gradient regardless of temp...frankly this can be done simply by measuring IHS temp and adding 5C to it...drilling hole with thermocouples is not necessary.
Just so you know, the idle temp of 53C was with C1E enabled, but EIST disabled. The two don't seem to tango with my motherboard, I end up stuck with a 6x multi. So I would be running at 1800MHz and 1.130V as reported by CPU-Z. I can't manually lower my vcore below VID. Right now I'm idling at 48C as it's a little cooler today. I haven't used the RealTemp calibration because at least for a Tj Max of 90C I don't think the adjustment ranges are quite large enough hehe. With a 70C Tj Max it would be 2-3C above ambient.Quote:
Originally Posted by unclewebb
If my E6600 isn't TjMax 90C then it must be nearly one-of-a-kind because most people's temps seem to fall into typical ranges, whereas mine is always higher. Heck, on a day where the ambient temp in my room would have been around 15C (which is uncommon here), my CPU was still idling supposedly at 32C. Perhaps the early batches had a different Tj Max even though they were the same stepping? This is only a week 28 chip. :shrug:
Funny you should mention this, I was going to suggest this in my previous post but decided you probably had better things to do :DQuote:
Originally Posted by unclewebb
EDIT: I don't know a whole lot about how this works, but C1E seems to have a fit when you change the power level. With an MSR 0x19A value of 0x16 or 0x14 the CPU alternates a 6/9x multiplier as well as the vcore very frequently even when I'm not doing anything. At 0x12 it is almost consistently running the higher settings and therefore the idle temp difference between 0x12 and 0x16 is no more than 1C. Is it because the maximum power level is so low that C1E "thinks" it is running a high load when usage is around 3% at the most? Task manager would confirm this, because if I set core #1 to 0x12 and core #0 to 0x02 then even a small load appears greater on the graph for core #1. If both are set to 0x12 then moving the task manager window appears to cause 50% utilisation on each core, whereas it is normally around 4%. If you look below, both cores show the same basic graph, but core #1 is much more pronounced.
http://i176.photobucket.com/albums/w...k_manager1.png
I'm just trying to work out exactly what is happening when you change the power level.
OK, I get that. But what I've taken from the discussion up to a few pages ago was that there is an unknown fudge around TjMax at the top end, where the sensors are supposed to be more accurate, then there is a bad slope with increasing error down to the low end where the sensors are definitely not accurate, giving extremely unreliable readings. But the last few pages seem to have provided a clear way to calibrate this low end very accurately, which should be possible by confirming the underclock state and getting the user to input cooling type and ambient temp, so at least one end of the graph, which previously was the worst end, can now be more or less dead accurate. Am I wrong here?Quote:
Originally Posted by unclewebb
Calibrating the high end is going to be impossible without some form of active temp measurement, I agree, along with a routine that can stress the processor until it throttles at a known distance from TjMax. But at least that end is supposed to be more accurate. If the DTS is officially based on TjMax, now published, does this new figure of TjTarget even matter? Ironically it seems this relationship to TjMax is being lost in the pursuit of this new obfuscation from Intel... :confused:
Here's a thought - given rge's testing of the gradients from core to IHS to heatsink, suppose someone were to market a cheap piece of kit - effectively a really BAD (or modded cheap) heatsink with a thermosensor mounted optimally in the base, linked to a simple thermometer gizmo that records the max temp measured. Now you have a stressing routine that breaks at PROCHOT asserted, you have a known DTS measurement this occurs at, and a known IHS temp this occurs at on a given chip. Wouldn't this fix the high end of the graph effectively without requiring ANY of these speculative and unreliable documented temp specifications, INCLUDING TjMax?
For any really avid overclocker (looks around at a captive and hungry market :D), this should be fairly simple to use to calibrate a given chip on a once-only basis, is obviously capable of reuse on newer sockets/processors with slight software upgrade and simple mounts (heck, make it compatible with the TRUE and 90% of the users here wouldn't even need any :rofl:) and it should be dirt cheap to make and still be pretty accurate for this purpose. Given what some people here are prepared to waste, um "invest", on graphics cards and SSDs, I can see a definite opportunity for someone with an engineering interest...;)
EDIT: Just wanted to add that the current method of calibration at the low end (underclock and idle) works without hardware, but isn't very useful for "normal" use as that point on the graph is way below "normal" usage, which is rarely going to be massively underclocked and idle for most people here :rofl:. If you had such hardware, it would be simple to have a piece of software that confirmed system idle at normal clocks and got a DTS reading/temp for that, then did the same for a 50-60% system load, then did the full stress routine to throttling. You'd then have three confirmed points on the graph to make a really accurate DTS/temp curve for each core covering the likely usage range, which might be importable into RealTemp somehow... ;)
Ian, after you set the correction to idle temp in Real temp using low volts and idle you have made the DTS sensors pretty accurate all the way up the scale. So once you overclock again, the actual temp goes up as do the sensors, in fact once fixing idle error since realtemp has slope error correction built in, thermocouple core reads temps same as realtemp all the way up, within ~1-2C error.
You'll appreciate my confusion as this apparently contradicts the previous reply from unclewebb:Quote:
Originally Posted by rge
If an auto-calibration of the inaccurate low end is possible in the way I suggested, which seems reasonable from your results, you have just confirmed that it would then be accurate all the way up the scale, assuming the TjMax value used to fix the top end is legitimate. That was my understanding too, that the top end DTS scaling was more accurate and therefore reliable.Quote:
Originally Posted by unclewebb
So where is the impossibility? :confused: It just seems a logical extension of the current sensor testing routine to me that removes a little of the user error possible in initial calibration by "guessing" offset values to put manually in the INI file. :shrug: You can read the chip voltage, the FSB speed and system load to confirm the correct underclock setting for calibration, then get user input on the cooling setup and ambient temps and use your gradient calculations to convert the current DTS to an actual temp. It seems dead simple to me, sorry. Isn't that what computers are supposed to be good at, doing calculations to remove guesswork and save time for their users? :ROTF:
Obviously if all that is required is the low end calibrating properly, then there's no need for elaborate (even if cheap) hardware to compare actual IHS temps with direct DTS readings.
randomizer: I think it was rge that had a theory that perhaps TJ Target and the actual TjMax were very similar during early manufacturing but as the process matured, the actual Tj Max for the B2 processors might have been bumped up a few times by 5C notches. Intel has been telling us since day 1 that we can't use these sensors to report accurate core temperatures and if TjMax was being quietly adjusted then that might explain the big secret. I haven't played with the Clock Modulation settings with C1E enabled yet. I'll give it a try.
IanB: You make some good points. It was always my belief that if you did a RealTemp calibration at a fixed low power level that you would end up with some reasonably accurate temperatures from idle to 60C where most users run their CPUs most of the time. rge's work and recommendations improves upon that.
And there is the problem. The latest IDF news release has shown me that Target TJ values and TjMax may not necessarily be the same thing. The RealTemp calibration will automatically minimize a couple of degrees of error in TjMax but it can't compensate for a 20C error in TjMax.Quote:
assuming the TjMax value used to fix the top end is legitimate.
For most of the mainstream 45nm processors that Intel says are TJ Target 100C, we now have two fixed points on the temperature curve and with a calibration, you can get accurate core temperatures from idle to TjMax.
Unfortunately the whole calibration concept really hasn't caught on even amongst the hard core community at XS. It's very rare that I see a screen shot posted where the calibration feature is being used. The majority of users seem comfortable accepting the fudged up DTS sensor data as is and don't want RealTemp fudging their data to make it look nice.
100% accurate temperatures aren't that important with Intel Core processors anyway. If you're overclocking and not stable at full load because of too much heat then you need to buy a bigger super cooler or reduce your MHz and / or core voltage so that your Distance to TjMax headroom increases. If you're stable and not thermal throttling, you can safely ignore your core temperature.
Thanks Unclewebb. I have a g0 overclocked to 3.0 ghz Vcore 1.26 VID is 1.250. My case is a Lian LI PC-A60C doesn't yield a good cooling for overclocked systems but is good. My temps are 40 - 39 - 36 - 38 idle with now the TJMax of 100.Quote:
Originally Posted by unclewebb
Thanks for response.
That theory works well with the B2 stepping at least. I intend to try and find the answer to this, as well as what Tj Target actually is and how it relates to Tj Max. I managed to accidentally catch the attention of some Intel engineers, so we'll see.Quote:
Originally Posted by unclewebb
This is good to hear, considering a few weeks ago you were saying it wasn't possible at all :)Quote:
Originally Posted by unclewebb
The testing by rge has renewed my faith in these sensors. They're not all bad. I've always had pretty good success but some of the recently released Intel documentation was making it seem more like a hopeless cause. I thought they were bashing them so we'd run out and buy some new Core i7 CPUs. :)
I originally thought TjMax was a lot more fixed than what it might turn out to be. At least TJ Target helps explain why some processors like your E6600 don't make any sense when using traditional values for TjMax. Now we just need more users to do some calibrating so it catches on.
Intel did say that Target Tj can be changed, but if Target Tj is Tj Max, then a 20C change is pretty drastic. It's certainly beyond what I would consider a part-by-part calibration. It could indicate a huge improvement in the heat tolerance of the process I suppose. What Intel needs to do if Tj Max is changed alot is:
1) Give us all of the different values that were used in the past (and future would be nice too :D).
2) Tell us when they were changed. At least if a user looks at what week their CPU is, they could work this out. Of course, this assumes that Intel changed the Tj Max for the entire stepping at certain points which might not be the case.
Of course, if that huge difference is just part-by-part calibration...
oops double post
There is no cpu, early pentium, 65nm, or 45nm that has a gradient less than 20-25C between tcase and hotspot (DTS) on full TDP load at stock settings, however there was a 10C gradient between cpu diode and tcasemax on pentiums prior to DTS being fully implemented.
My pentium 4 that I drilled a hole in has a tcasemax of 69C. It throttles then cuts off at a 80C controlled by cpu diode not DTS (hot spots), so it has ~11C gradient from tcasemax to tj target using cpu diode. But the cpu diode on a pentium underestimated load hot spots by 15+C (per research paper in earlier post) and this tjunctionoffset in pentium docs was defined as max difference between cpu diode and hot spots (pic of doc below). The pentium throttling at tj target of 80C by cpu diode (11C gradient cpu diode to tcase) knowing hot spots were 15C higher (tjunction offset) is no different then setting tj target 95C by DTS (26C gradient DTS to tcase).
Then came DTS sensors that accurately captured the hot spots, additionally the cpu diode started approximating hot spots more closely via die shrink (65nm intel temp research paper). Initially cpu diode (not DTS sensors) were still being used for throttling control even after early incorporation of DTS. I now have no doubt the original tj target on 65nm were planned to be 10C based on cpu diode temps, prior to fully switching to DTS for throttling control, and prior to research on 65nm samples illustrating the decrease offset between hot spots (DTS) and cpu diode and the proven ability to accurately capture hot spot temps.
Intel stated that the DTS was calibrated upward to prevent throttling below tcasemax, which means all cpus that were made with that requirement based on DTS throttling not cpu diode have a tjmax at least 20-25C higher than tcasemax, quads a few C higher based on 45nm known values. The fact that my E6850 tjmax was 98-100C by IR, and unclewebbs E6600 was tjmax 90C by IR...to me puts the issue to rest for more recent models, especially given slide 7 and 13 with graphs showing large offsets. I just dont know exactly when DTS sensors became the throttling control instead of cpu diode (and when docs changed to reflect this), and when the research was done (only know when published) so that intel knew the exact gradients, relationship, and DTS accuracy for hot spots so they could aggressively set tj via DTS.
Thanks for the background info rge.
From what I've read, I thought the first DTS sensors were introduced into the late Pentium 4 CPUs but I haven't found any users that could read this data from their P4. Anyone that wants to try can use my MSR Tool and read MSR 0x19C where the temp info hides.
http://img46.imageshack.us/img46/1112/tempinfogb3.png
Those two digits contain the DTS data and should decrease as the core temp goes higher. It would be interesting to see those numbers go up and down on a late P4 when the load changes. You'll have to manually click on the Read MSR button to check for any changes.
Edit: rge, I was just reading the P4 docs and it shows the IA32_THERM_STATUS MSR just like the Core processors use but there was no mention of this MSR containing any temperature data. The two bits of data in this MSR that RealTemp uses to report Thermal Status as OK, LOG or HOT when thermal throttling is active and listed as functional in the P4. If you want a version of RealTemp that will work with a P4 to at least read this information then let me know. The temps will be meaningless but those flags should light up. It would be interesting next time you do some P4 testing.
Unclewebb, would have loved to have that ability to use realtemp to read that reg on P4 prior to its current state...I had bright idea in my drilling phase to guess at a non critical place to drill deep into the core to compare to surface of core, funny thing it still works computer sounds like its booting windows...but no video...but also carelessly broke 3 pins on edge from not protecting them while drilling...may try something metal to replace pins as may not be the hole but pins causing lack of video...if I get it fixed I will let you know.
rge, how many CPUs do you have lying around to drill? :eek:
http://www.xtremesystems.org/forums/...postcount=2394
pic of 3 drilled, my E8400 makes 4th (post 2438), my E7200 would be 5th but fried it running it delided trying to measure temps that way, which I learned is impossible...the IHS is an incredibly effective heatsink and heatspreader...last recorded temp on my E7200 was 138C (thermal monitor disabled) still dont know if it shorted or fried from heat... but my E8600 I just got is not getting touched, except having fun seeing what it can do:D Besides at this point I am confident I would not learn anything else, just see same gradient, so I have already satisfied my curiosity...so no more drilling...probably.
And people are afraid to run prime95 when they hit 60C... WITH a heatsink. :rofl:
rge: When you get bored playing with your new E8600 maybe I'll send you my Pentium E2160 for a drill job and some testing. It only has 1MB of cache and compared to the E8400 with 6MB, the E2160 heats up very slowly without a heatsink on it. Nice HTPC type chip. I sometimes prod it with some Prime action to get the temps up there but even with no heatsink or fan, the temps drop quickly when you stop Prime. That IHS lid is definitely working. It might provide us with another calibration point for chips with smaller amounts of cache.
I'll probably drill one of those cheap, Intel OEM, all aluminum, low profile heatsinks first and see if I can get any usable data from it with the IR thermometer. I also have a consumer grade probe to shove in the middle of it but I don't know what quality of data I'll get from that.
anytime...but if trying it there...I could not get temps through a drilled hole in a heatsink with IR, despite laser spot being small, but because the IHS is such a good heatspreader, placing any heatsink on 1/3 of the cpu IHS with paste and leaving the other 2/3 uncovered for IR, I could get accurate die temps (-5C gradient), even without drilling into a heatsink (after comparing that to drilled die temps). Doing it that way near 1.1 vcore, I am confident adding 5C (2-3C IHS and 2-3C across die mold from sensors) will get you accurate die temps the same as measuring top of die and adding 2-3C. At 1.4-1.5 vcore and idle like on the pentium or E8400 at that voltage you get a 4-5C gradient across IHS and 4-5C across die mold, anything in between can be extrapolated. Of course the one fallacy will be if as you say E2180 puts out a lot less heat, but I bet it is going to be similar, given the idle temp similarities in my pentium 4 and E8400, despite their differences in specs both simply scaled the same with voltage.
Or if tape half cpu for IR and put a pea size ball of thermal paste just next edge tape in center to completely envelop tip of thermocouple as pressed up against IHS and using different idle voltages to regulate temp, you can "calibrate" thermocouple ie if always reads 5-7C below IR temps (unless inserting thermocouple inside IHS) but need to "calibrate" at middle range and high range to make sure same error. But using that method, need to keep the thermocouple from moving to much as spinning it around can change calibration 1-2C.
Just to clear things up, I've heard from a reliable source that TJ Target and Tj Max are the exact same thing and that Intel wasn't trying to add more confusion to this subject.
I wrote back and tried to explain the problem I have with that:
"If I use TjMax=70C for my B2 I end up with idle temperatures during my calibration test that are reported approximately 17C below my room temperature and based on rge's recent testing that has to be a good 23C below the actual core temperature. There is a couple of degrees of slope error in the 65nm CPUs but certainly not that much.
There's the dilemma I have. If I follow Intel's recent guidelines for 65nm, I am going to end up with a lot of unhappy users and my program will likely become the laughing stock. Intel's version of things just doesn't seem to fit with the testing that rge and I have done on B2 and G0 Dual and Quad Core processors."
Based on that, I don't intend to change the TjMax that RealTemp is presently using for the 65nm processors. If an individual user thinks that the Intel recommended TjMax is correct for his CPU then by all means go ahead and use it. All I can say is that there seems to be a lot of 65nm processors out there that don't fit Intel's recent TjMax news release.
rge: I can't wait to fire up the drill and get back to testing but at the moment I'm trying to concentrate on the programming side. Initial testing of the new Core i7 looks good. They seem to have really tightened up the specs for their sensors.
http://img513.imageshack.us/img513/5599/tightpm3.png
45nm Intel Core 2 Duo owners can only dream about their temperatures looking that consistent both at idle and under load. This Core i7 Extreme 965 (ES) model is using TjMax = 100C. I'll improve processor recognition when I see some official Intel documentation.
The only sad part is they're going to put RealTemp out of business. Any software should be able to get some reasonably accurate core temperatures out of Core i7 without having to guess at TjMax or needing a calibration or correction factors or anything else. RealTemp 2.82 is reading the default TjMax info from within the CPU. As soon as I get confirmation that it is working properly, I will release the latest beta here.
Hmmm, upon further review, maybe there's still room for a little slope or TJ Target correction with Core i7.
Some sensor isn't being 100% honest. :)
http://img125.imageshack.us/img125/8429/slopeez4.png
I wonder if it is a disconnect between intel person doing the explaining and the ones that actually know, or if they are simply leaving something out, like what tj refers to cpu diode or DTS, whether there are 15-20C offsets on 65nm and not on 45nm.
In addition to the idling subzero issue (low end ridiculous), I would send the intel person (if that is source) two pics (high end ridiculous as well). One, fluke IR demonstrating E8400 IHS temp is 5C lower than die temp using intels 45nm 100tjmax, which is very plausible. Second pic exact same fluke IR, exact same method, demonstrating an IHS defying the laws of physics being 15C hotter than the die using intels wacky 65nm tjmax....and as nicely as possible imply you will stop laughing when they can explain that. You can argue absolute error on IR (though couple C not like that), relative error you cant with a straight face.
Of note coretemp author isnt changing tj based on 65nm either.
Edit: let us know what they respond with...cant imagine
Is RealTemp 2.79.8 the latest version? I searched back like 10 pages and couldn't find anything newer, thank you in advance.
Hi Captn Sponge Bob. Long time no see around here. RealTemp 2.79.8 is still the last official beta. I've been taking it easy lately while the TjMax / TJ Target debate gets sorted out. I've added proper reading of TjMax from the new Core i7 processors recently but not much else. I might quickly add in throttling control to help users check for sticking sensors. I have a few ideas for some new features. I just need to find the time to implement them.
Quote:
Originally Posted by unclewebb
Does this CPU have the issue with the stuck temp sensors? http://www.newegg.com/Product/Produc...82E16819115041
When are the Core i7's do out ?
I have read dates between Nov 3rd and Nov 16th.Quote:
Originally Posted by Captn
So somewhere between soon and very soon... :yepp:
All 45nm CPUs like the Quad you're looking at have sensors that might stick and not report accurate temperatures below 50C. That's just the nature of the sensors that Intel used since they were designed for thermal throttle and shut down control and not for accurate core temperature reporting.Quote:
Originally Posted by Captn
The good news is that the Core i7 will be out later this month. I've heard two weeks from today, November 15th, but that's just a rumor. Their temperature sensors seem much better during early testing.
Thank you, Any update on the rumors?Quote:
Originally Posted by unclewebb
Quote:
Originally Posted by unclewebb
Awsome thanks, guess i'll wait a few weeks to upgrade then...lol. :D
If you're talking about the release of TjMax for 65nm then yes, Intel did release lots of new information.Quote:
Originally Posted by Demo
jaredpace did an excellent job of summarizing it. I think he might of borrowed these nice charts from Tom's. :)
http://www.xtremesystems.org/forums/...postcount=2400
The only problem now is that the TjMax numbers for some / many 65nm processors don't seem to agree with IR thermometer testing that rge and I have done.
A good example is my E6400 B2. When DTS=0, the surface temperature of the IHS is 85C and given that there is approximately a 5C gradient between the IHS temperature and the core temperature, that implies that the core temperature is 90C. Intel says that a B2 E6x00 Dual Core processor has a TjMax=70C. Sorry but I don't believe that. rge has ended up with similar inconsistencies when he has looked at the results from his E6850 G0 which Intel claims has a TjMax=80C. Once again, that number is in total disagreement with what an IR thermometer says.
So far I haven't changed any TjMax values that RealTemp is using. I'm hoping that Intel will come up with some sort of explanation for this but at the moment I can't think of anything. I think my Fluke IR thermometer is rated as +/- 1C at that temperature so there isn't much room to argue. TjMax=70C would also result in my idle temperatures being reported 17C below the room temperature which is about 23C below the actual core temperature. TjMax=70C doesn't make sense at either end of the temperature curve.
As a user, I'd keep using the present beta of RealTemp and calibrate the low end / idle temperature based on rge's recent findings:
http://www.xtremesystems.org/forums/...postcount=2429
What is the Xeon XE and XEE? I've never seen them mentioned before, but they were on the slides. Xtreme Edition and Xtremely Elegant Edition?
More like, Xtremely Expensive Edition!
http://www.fileden.com/files/2008/3/...alTempBeta.zip
It's been a long time since the last beta. I guess I finally got tired of waiting for Intel to clear up the TjMax confusion. :)
Not too much new. This version should properly recognize and report the new Core i7 processors and properly read the TjMax information that is within them.
A new feature has been squeezed into the Settings window called Clock Modulation. It allows easy access to this feature that is built into Intel Core based CPUs. I haven't tested it on Core i7 yet but I think it will probably work on those too.
It allows you to run your CPU at a reduced power state from 12.5% to 87.5% of your normal CPU power.
Possible uses?
How about faking a screen shot for your buddies? CPU-z etc. will report your CPU running at top speed but internally your CPU will only be running at a fraction of that speed which will keep the temps nice and low. A perfect way to con your buddies into thinking that you have an uber cooling solution cause you're running Linpack at some crazy MHz setting but your temps are well in control. :D
A more practical use might be in testing an overclock. If you are running a nice overclock but always seem to get an error when running Prime then you could set the Clock Modulation to 75.0% which will allow your CPU to run a little cooler. It might help you isolate whether your instability is heat related or not.
The primary use I've found for this new feature is that it can do a better job of detecting sticking sensors.
My test method is to run a program like Prime95 with the small FFTs option. This will create a very consistent load and temperature for your CPU. When the temperature has stabilized at full load, turn on the Clock Modulation feature and set it to 87.5%. Your temperatures should immediately drop a couple of degrees on each core. Wait a minute and then go down another step to 75%, etc. and keep decreasing this until you are at 12.5% and then for the last step, stop Prime95. I've found that after you stop Prime95 that you can decrease power consumption and your CPU temperature by turning off the clock modulation feature.
If your sensors are working properly you should end up with constantly decreasing temperatures on each core. A SpeedFan graph will look something like this:
http://img145.imageshack.us/img145/6708/clockmodfp6.png
If half or three quarters of the way through this test you notice that your temperatures stop decreasing then that is a pretty good sign that your sensor is sticking at that level. Instead of having a stair case, the temperature graph will have one very long flat section. In SpeedFan I waited about 90 seconds at each stage to draw this graph. I believe that no temperature decrease during any stage of this test is a warning sign of a sticking sensor.
I don't have any CPUs handy with known sticking sensors so I hope someone will try this test and post what it looks like. If this test is useful then I will try to automate the procedure as much as possible so you'll be able to click one button and walk away for 10 minutes or so and come back and see the results. I'll average the temperature at each level and try to include a small graph to make the results easy to see.
If you want to see what effect Clock Modulation has on the performance of your computer then set it to 50% and run a not so quick XS Bench or try to run Super PI. It will be like someone tied an anchor to your back bumper.
Happy testing.
Yeah, went from 16 sec to 37 sec in SPi. :DQuote:
Originally Posted by unclewebb
I'm glad you're back on RT but you know what I'm waiting for...
Thanks man for your work. :up:
I ran the XS Bench when I produced that graph a page or two back using your MSR tool. I don't know much about it, is it single-threaded? It doesn't seem to be badly affected by running one core at 100% and one at 12.5%, it takes only a few seconds longer. Running both at 12.5% takes several minutes though.Quote:
Originally Posted by unclewebb
EDIT: The link goes to the old version 2.79.8.
The link is fine, try to empty your browser cache.Quote:
Originally Posted by randomizer
http://img404.imageshack.us/img404/5116/rt283dp6.png
just tested on i7-965 and working perfectly.:up:Quote:
Originally Posted by unclewebb
many thanks for your hard work here.:clap:
Done but still getting the old file. How is that possible? :confused:Quote:
Originally Posted by burebista
I'm even downloading it on a newly installed OS, so my cache wouldn't have even had it in the first place. Unless it's my ISPs transparent proxy caching the file.
EDIT: Got the right file with IE7, so for some strange reason FF3 was getting the old one.
Firefox and the fileden site I use like to fight it out sometimes.
If Firefox keeps giving you an old version of RealTemp then click on:
Tools -> Options in the Firefox menu and Clear your cache:
http://img89.imageshack.us/img89/8056/optionsmd7.png
randomizer: The XS Bench is only single threaded. It's just a quick bench to make sure your computer is running more or less properly. It is small and fits in the on CPU cache so it isn't effected by your memory timings or anything else for that matter. It's very proportional to your CPU MHz and that's about it. It's strongest point is that XS Bench is very consistent and can detect even tiny changes in performance. A FSB change of 1 MHz should be easy to see in XS Bench.
Thanks Movieman for testing RealTemp on Core i7.
Intel hasn't quite got around to sending me a new Core i7 board and CPU to do some development work with. :(
No need for anyone to post a screen shot and risk getting in trouble but are the Core i7 reported temperatures much closer together and more consistent from idle to full load than the previous 45nm generation? They seem to be.
I heard that NDA is lifted on Monday, so we should hopefully get some screenshots after then.
EDIT: Page 100!
Thanks for your work unclewebb. :)
:rocker: :worship: :worship: :worship: :worship: :worship: :rocker:
Congratulations on 100 pages of excellent information people. And great job webb. Cheers.
Ditto!!!Quote:
Originally Posted by Ol'Baditude
Thanks for the thumbs up guys. Stuff like that gets me motivated.
I've been doing some background work recently and tonight I started programming a more advanced sensor test. I've got the general layout done and have started hooking it up. This test will take about 10 minutes but I'm making it very user friendly and I think it will give users a much better look at exactly what their sensors are up to. It goes well beyond the present Sensor Test and it should be much easier to find sticking sensors with it.
Here's a preview:
http://img208.imageshack.us/img208/8...sortestao5.png
My present backdrop should be titled, "Wishful thinking." :)
that's GREAT uncle! :up: can't wait to get my hands on v2.84 :D
That look AWESOME!!! Looking forward to it.
Thanks Uncle for all the effort you have put itno this, IMO there is nothing better out there. :up:
Thanks to burebista for sending along this screen shot.
http://img89.imageshack.us/img89/6682/tjmaxcy1.png
Model Specific Register (MSR) 0x1A2 is where TjMax is hiding in Core i7. Thanks Intel.
This might significantly reduce the million and one posts about, "What is TjMax?"
In the picture, 64 hex translates to 100 decimal so it looks like TjMax=100C for the early Core i7.
You can use any program that lets you read MSR data to check your Core i7 or you can use the MSR Tool
at least the new Core i7s don't seem to have stuck sensors
Looking good, can't wait!
That makes them boring :p:Quote:
Originally Posted by emoners
I always love seeing those flat line in all 4 core temps on a quad, mine looks like 63-63-59-59 on load =(
I just completed my first CPU Cool Down Test. It takes just over 10 minutes and is about as exciting as watching paint dry but I think it will give users some useful information about how their sensors are working. I'm sure Intel is going to be real happy with this test. :D
This test uses Prime95 small FFTs for consistency. I was running 4GHz at 1.40 volts with my Tuniq on low speed to create a nice temperature spread from full load to idle.
During testing I noticed that when using the Clock Modulation feature that as a CPU throttled down, my Kill-a-Watt meter would show less and less power consumption. In theory, every step down in power consumption should translate into a lower core temperature. A person should see the Distance to TJMax increase at each and every step going down in the chart.
Here's how my test looks on my E8400 that doesn't have sticking sensor issues at normal room temperatures:
http://img91.imageshack.us/img91/5126/cooldowngr4.png
I think a processor with sticking sensors when running this test is going to get about half way through it when it will be very obvious that the sensor has stopped moving. If the power decreases to the CPU and the CPU keeps reporting the same Distance to TJMax then that is going to be an easy way to see that one of your temperature sensors is stuck.
Hopefully within the next 24 hours I'll have a version ready for download.
Anyone out there with some stuck sensors that need testing? :up:
hi uncle,Quote:
Originally Posted by unclewebb
do we have to look at dts temps and check "manually" if the sensor stopped moving, or are you considering to let realtemp check if dts movement stopped? would be nice to let realtemp itself check if the sensor stopped moving and pop up an error msg and probably even stop the cool down test if this happens ...
link plsQuote:
Originally Posted by unclewebb
Hopefully within the next 24 hours I'll have a version ready for download.Quote:
Originally Posted by Factotum
that's what he said at the time of posting
We`re looking forward to get it.
fgw: The first thing I need to do after releasing this new test is to get a lot of feedback from users that have CPUs with good sensors. Most 65nm and the new Core i7 seem to rarely get stuck. I'll also need to see what this new test reports on 45nm CPUs with known stuck sensors.
It might not be until the 25% mark that a sensor first sticks and then I would still have to run a couple of more rounds after that to confirm it. Sensors also tend to stick at slightly different values so after the first sensor gets stuck the test would still need to be run further to see what the other sensor or sensors are up to.
This test isn't designed to be run everyday so stopping it at the 8 or 9 minute mark instead of letting it run for the full 10 isn't going to save a user a lot of time. This test was designed more for when you first get a new chip so that you can get to know your sensors reasonably quickly and see if you have any duds or not. It should also provide a thorough baseline that you can compare to later.
There is a wide range of CPUs with large differences in temperatures from idle to full load depending on cooling, core voltage, etc. That makes it difficult to create a simple formula to interpret this data and pop up an accurate message that says, "ERROR!, Your sensors are junk."
To begin with, I'm going to let users interpret their own data. Maybe I'll get more feedback that way.
Edit: 12 more hours. :)
Here's a second test with the same CPU as before at closer to default settings with SpeedStep / C1E enabled. With Prime95 running, it was at 3000 MHz and 1.200 volts and dropped to 2000 MHz and 1.192 volts when RealTemp stopped Prime95 at the 0.0% level.
http://img223.imageshack.us/img223/5...wntest2sm9.png
The final Idle level is when the CPU Clock Modulation feature is turned off. Power consumption at the wall drops again and the CPU cools down one final step.
When not overclocking and testing at default values, the data continues to look pretty clear. Based on this test I can conclude that both sensors are well balanced and don't exhibit any sticking issues at a Distance to TjMax of 66 or less.
A few more hours and it will be ready for release. :)
At first I thought your temps were going up as CPU load was dropping. :eek:
Note to self: read the labels.
you rule :)
unclewebb
Comon, mate? Where are you :D
Based on the MSR tool's reading, what is my TJ max for the Merom T7100, Unclewebb?:shrug:
Since that's a mobile chip, you can just look it up on the processorfinder. It's 100C according to the thermal spec. If only Intel was as clear about desktop chips. Of course, in the case of a known Tj Max (like for mobile chips), you could just add the temperature to the "Distance to Tj Max" together ;)