![]() You can see how this can get very confusing. Also note that in the above screen shot showing a 5x multi (0.99.7.1 now shows 5.0 too), technically it is a 10x multi with SLFM enabled 100% of the time. For instance when showing a multi of 6x the user now has to check BCLK or Freq to see if it's say 133 x 6 or 266 x 6 whereas using an effective multi (3x) it is immediately obvious. While using an "effective BCLK" may show a technically correct multi it does have some disadvantages. ![]() Whether to report an "effective BCLK with technically correct multi" or a "technically correct BCLK with effective multi". IMHO reporting SLFM and FSB dynamic switching comes with it's own problems. There is also a new Media Center addon to see your CPU status here: Update: Added missing Intel Socket names. Update: Rearranged the main GUI and added new information. Fix: Overheating protection on AMD processors bug. ![]() Fix: G15 plugin restarts after resuming from sleep even if it was previously disabled from the menu. Fix: On some systems the System Information window would flood the screen with errors. Fix: Minor Intel processor recognition issues. Fix: Reading and logging intervals in Settings can't be changed. Fix: Frequency doesn't update after exiting from Sleep or Hibernation. New: Displays the processor's manufacturing process. New: Support for the E3000 Celeron series. New: Proper support the Phenom II X6 and Athlon L100 series. New: Clock modulation detection for Intel processors. New: Implemented Windows 7 taskbar button features. 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? That's useful information to me and many other users. 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. ![]() 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.Įven when a sensor is not 100% accurate, they tend to be very consistent from day to day. Intel's statement is a worst case but it doesn't apply to all sensors. There are many 45nm sensors that work very well below 50☌ and don't get stuck at normal operating temperatures. 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. Some of what they have publicly stated about their sensors is misleading. Temperatures below 50☌ should be ignoredĭon't believe everything Intel says. Now I have to go fix a few bugs in RealTemp to try and get caught up. I tried 101 tricks to fool it but everything looks good. 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. That's why RealTemp has a calibration option for those who want to approximate "real" values for core temps in idle. Two years ago unclewebb, rge and others did a wonderful job debunking those cheap Intel sensors readings and guesstimate various TJMax values. 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. Then you can guesstimate what you want.ĮDIT: Trying to make sense of nonsense data (high entropy) seem more fancy to me than something else. Once it gets saturated at certain threshold, the values returned below might be totally irrelevant and not corresponding to real situation. ![]() I don't think that anything can solve a problem of hardware inaccuracy of a sensor. Determining a correct Tj,max for a particular CPU is something different. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |