Thanks for taking the time to test it out :)
Ok, I think I got it now. same links
Printable View
Thanks for taking the time to test it out :)
Ok, I think I got it now. same links
SAA-WEEAT! Thank you very much. Now I know my D0 i930's temps and loads:up:
Version 0.99.6.7 show correct.
I did more research on the accuracy and on most Core2 and Atom CPUs:
- Temperatures below 50°C should be ignored
- At temperatures ~ 50°C the inaccuracy is 10-15°C so not very usable too.
Man maybe you miss this thread. ;)
Two years ago unclewebb, rge and others did a wonderful job debunking those cheap Intel sensors readings and guesstimate various TJMax values.
That's why RealTemp has a calibration option for those who want to approximate "real" values for core temps in idle. That's why RealTemp (and now CoreTemp too, kudos to The Coolest for taking Kevin's advice :up:) are two almost perfect tools for showing real data for Intel CPU's not only fancy colors or graphs. ;)
Determining a correct Tj,max for a particular CPU is something different.
I don't think that anything can solve a problem of hardware inaccuracy of a sensor. Once it gets saturated at certain threshold, the values returned below might be totally irrelevant and not corresponding to real situation. Then you can guesstimate what you want..
EDIT: Trying to make sense of nonsense data (high entropy) seem more fancy to me than something else.. I know there was a large effort to achieve that, but I don't think it's possible - it will never be accurate for certain models.
Core Temp 0.99.6.7 is working great. I tried 101 tricks to fool it but everything looks good.
Now I have to go fix a few bugs in RealTemp to try and get caught up. :)
Don't believe everything Intel says. Some of what they have publicly stated about their sensors is misleading. Most of the Core 2 65nm sensors are excellent when you are using the correct TJMax and not Intel's TJ Target numbers that they also released at the IDF conference. There are many 45nm sensors that work very well below 50°C and don't get stuck at normal operating temperatures. Intel's statement is a worst case but it doesn't apply to all sensors. I've seen bad sensors in forums but all the Core 2, 45nm and 65nm, CPUs that I've owned have had very usable sensors.Quote:
- Temperatures below 50°C should be ignored
Even when a sensor is not 100% accurate, they tend to be very consistent from day to day. The data might not be accurate enough to make comparisons to your neighbor's computer but it is usually consistent enough to see if your computer is running hotter or colder than it was yesterday or if there was a core temperature change due to some hardware you changed. That's useful information to me and many other users.
If you believe Intel and think that all this data is bad then as the programmer of HWiNFO32, why don't you remove the reporting of this data from your program?
Cool, thanks.
Could guys with 655k and 875k post register dumps of Core Temp? I need this to add proper detection for these chips.
Is this any better than Real Temp for i7 chips?
By default, both of them should report the same values. Which one to use? I guess it depends on personal preference.
Ah, well Core Temp was reporting my CPU speed incorrectly unlike Real Temp. Still, both seem like great programs! :)
SimpleTECH, thanks.
Another strange issue that I've noticed is that Core Temp reports many nehalem CPUs having a default multiplier which is lower by x1 than the real multiplier.
See x21 in the register dump when it's supposed to be x22.
Could you please post a Core Temp/CPUz screenshot and a cpuz Report?
I just tried version 0.99.6.8 64bit with my q6600 and whilst the fsb frequency is now correct, the multiplier at idle read 7 when it should be 6 (with 8 at load which is detected fine)
EDIT: the 32bit version shows the multiplier of 7 as well
EDIT2: The latest beta of realtemp (3.59 i believe it was) also has the exact same issue
same here.
@ SimpleTECH: That's what I thought, thanks. But does CPUz still detect it properly, even at x21?
We changed the algorithm of cpu frequency detection.
Instead of just reporting the static multiplier every second we now calculate the average frequency every second. Since EIST is quick, it may report a little higher frequency than you ever saw before, in any other application.
Isn't 21 the HFM and 22 a turbo bin?
Tried a quick run on high multiplier and coretemp seemed okay except there was a short time it was showing 60.5 instead of 60.0, the maximum set. Realtemp and i7 turbo seemed to stay at what was ever the highest set multi when started (32x at the time) but when the programs were closed and restarted they seemed to pick up the higher multi okay.
http://img514.imageshack.us/img514/8231/tempo.gif
Here's a 655k coretemp dump.
It's time for 0.99.7 ?;)
Yep, coming very soon :)
The multiplier at idle is likely showing 7 because you don't have your computer set up correctly. If you want a 6 multiplier at idle then you need to have your Control Panel -> Power Options -> Minimum processor state set to a low percentage like 5%. What OS are you using? Windows XP has a slightly different adjustment to take care of this. At idle your CPU really is bouncing the multiplier back and forth between 6 and 8 and averaging about 7. That's why it reports the 7 multiplier. Having the Minimum set to 100% and C States enabled can cause the multiplier to hunt up and down at idle.
some_one: Thanks for posting that. I knew RealTemp was going to have this problem with these new CPUs because it doesn't recalculate the base multiplier. Before the K CPUs came along, the base multiplier was fixed and never changed so I thought it would be more efficient to only calculate that once. I'll get that fixed up in the next release, hopefully later today.
Thanks unclewebb, that explains it i'll change the power setting btw i'm on win7 x64
Here is a 875K