RealTemp BUG?

[Arctucas]

In for a penny, in for a pound...

And having polished off a half a fifth of Jack Daniel's, I am feeling no pain at this point.

First, I have AIDA63 set to update every one (1) second, so uncleuebb's assumption is somewhat flawed (I still believe you have a great piece of software though).

Second, my i7 950 core temperatures line up in both AIDA64 and RealTemp, except that occasionally AIDA64 reports Core 1 (0) and Core 2 (1) temporarily higher (as in about a second or two) before returning to match RealTemp. Core 3 (2) and Core 4 (3) appears to match RealTemp consistently.

For what it is worth, and I am sure unclewebb and Tamos would both agree, software monitoring is imprecise at best, and in actuality only gives an estimation of reality.

 

[N9ZN-Extra]

In for a penny, in for a pound...

And having polished off a half a fifth of Jack Daniel's, I am feeling no pain at this point.

First, I have AIDA63 set to update every one (1) second, so uncleuebb's assumption is somewhat flawed (I still believe you have a great piece of software though).

Second, my i7 950 core temperatures line up in both AIDA64 and RealTemp, except that occasionally AIDA64 reports Core 1 (0) and Core 2 (1) temporarily higher (as in about a second or two) before returning to match RealTemp. Core 3 (2) and Core 4 (3) appears to match RealTemp consistently.

For what it is worth, and I am sure unclewebb and Tamos would both agree, software monitoring is imprecise at best, and in actuality only gives an estimation of reality.

I set them up side by side several post back and did not get agreement with Real Temp and AIDA64. I agree nothing is expected to match up 100% and monitoring is imprecise.

I am almost sorry that I even began to try to calibrate Real Temp. It seemed like a really good thing to do at the time and has ended in nightmare (of sorts). All I ever wanted to accomplish was to get a few temp readings which were close enough to allow comfortable overclocking of the PC above 4.0 Ghz along with components without frying the motherboard, processor, NB, SB, GPUs, or RAM.

I really did appreciate your metioning the AIDA64 OSD as I had forgotten about that feature. I do not like all the extra data on the screen most of the time but I also have a logitech G15 so I can monitor the data on the keyboard instead using the LCD settings in AIDA64. I would assume it should be the same as the OSD data. It is a little surprising that any of the data should be read differently since that would only add to more code to accomplish reading the same sensor. I am staying out of that discussion however since it would yeild nothing productive for my purpose.

In the past on several ocassions I had run multiple temp monitoring softwares (including AIDA64 / Everest) and knew they were all fairly consistent with readings across the group. Real Temp was never a part of that group or I may have noticed this sooner. BTW that is the reason I did not desire to go back and re-load all of the other temp monitoring junk on the PC, I try to keep my registry as clean as I can and loading software just adds to the build up in the registry. I already knew they would be in close agreement. My level of resentment of the comments about running more monitors just made me keep my mouth shut concerning past comparisons. You know whats the funny part of this is, even if I had run 200 other temperature monitors UNCLEWEBB himself said in so many words that Real Temp is the only one where a correction has been made. That's the way it came off to me after reading his comments.

Maybe something else is going on with my PC and the temp monitoring software. If Real Temp and AIDA64 OSD are in agreement on your PC and they are not my PC. If that should be the case I do not have a clue what it might be. The only thing I do know is AIDA64 and other software pretty much agree with each other across the board.

Enjoy the JackD, Kentucky burbon never agreeded with me and I gave up alcohol years ago. Not because of a problem, I just quit buying it. I don't even remember why, to save the money I guess.

 

[unclewebb]

When the APIC ID is reported sequentially, RealTemp will report the data in the same order as every other program out there. The problem on your computer N9ZN-Extra, is that the APIC ID is screwed up. This happens. Whether you want to blame the bios or blame Windows for not dealing with this doesn't matter. At least now you have an explanation of why RealTemp is different. Most of the newer motherboards don't seem to have this issue so I'm not going to bother giving RealTemp a work over to try and explain this better. People can do a Google search and will hopefully end up here sooner or later for an explanation.

If the temperature sensors were 100% accurate, you would not see huge differences in core temperatures from core to core when stress testing with Prime95 Small FFTs. The reason you see these differences has virtually nothing to do with an actual difference in core temperature. The majority of difference is sensor error. Try running Prime95 Small FFTs sometime for about 5 minutes. If the cores get hot enough, they start to get into a more accurate range.

As mentioned before, these sensors are junk and were never designed to be used for accurate core temperature monitoring. Intel already knows this so you don't have to contact them. They've never approved of any third part software like RealTemp converting the raw data from these sensors into temperature data because of the numerous issues these sensors have. These sensors are designed for thermal throttlilng and thermal shutdown control and that's it. They work absolutely fine for that purpose. They don't need to be super precise temperature monitoring sensors to do this job. If a CPU core throttles at 100C or 105C or 110C doesn't make any significant difference so Intel was able to use lower cost sensors without any ill effects other than quite a few angry enthusiasts.

so unclewebb's assumption is somewhat flawed

I'm not sure what assumption I made that was flawed. Let me know so I can clarify anything I posted. The temperature sensors on the i7-950 are excellent compared to the sensors that Intel used on their 45nm Core 2 CPUs. There's absolutely no comparison. I think Intel was embarrassed by just how bad their 45nm Core 2 sensors were so they spent a few more pennies when designing Core i7 and used much better sensors. Users stopped complaining so when they switched to the 32nm Core i7-980X, they started pinching pennies again and sensor accuracy decreased. Not as bad as 45nm Core 2 but definitely not as accurate as the original 45nm Core i7-900 series.

The 45nm Core 2 sensors include TJMax values with up to 10C of error and in some cases, likely more. They are not consistent from one CPU to the next of the same model let alone from core to core on the same CPU. These sensors can get stuck at any temperature below about 50C. They also suffer from considerable slope error which means the actual core temperature might change by 20C but the sensor will change by 15 or maybe 25 positions. Intel never fully disclosed or documented any of this because they didn't intend that these sensors would ever be used for accurate core temperature monitoring. They knew these sensors just weren't good enough for that but users didn't want to accept No for an answer so used whatever software they could get their hands on no matter how inaccurate it was. Not all of Intel's temperature sensors are horrible but many are.

This may sound odd but if you intend to overclock your CPU then you don't need to worry about the core temperature. The harder you overclock it, the sooner you will lose stability if it gets too hot. You will be well under the Intel designed thermal throttling temperature and Prime95 stability will go bye-bye if the CPU is too hot. As long as your computer is running stable and is not thermal throttling then there is no need to think too much about its core temperature. It's just a number and not a very accurate number regardless of what monitoring software you are using. The only thing you need to do is run your CPU as cool as you possibly can which will give you the maximum amount of overclocking headroom. There's no need to worry about anything else.

 

[95Viper]

Since you stated your position (opinion) I will state mine.

I respectively believe your opinion is wrong. I am doing Real Temp a service by bringing this to thier attention be there a bug or not. As for in depth testing that is for the Real Temp software house not I. I did test the product against what I had available to test against, AIDA64.

I did not say for sure Real Temp has a bug but after personally spending 35 years in Information Technology it would surprise me if it is a perfect application. I would bet it is not a perfect application if I were a betting man, the odds are heavily on my side.

As a PC user when things like this are seen we search for answers. Part of that search is to post here on the forums looking for a positive suggestion of what may be going on with the temperature discrepancy. I did not come here to promote and protect Real Temp nor did I do so at AIDA64 where I also posted.

Any company would be greatful to receive information about thier product especially if it gives them an avenue to state superiority over another brand. Those companies who are not as receptive to inquiries generally have things to hide.

Don't you believe others would like to know what the community is seeing? I do and I believe that is why they come here. I come here for information only and like anyone else I can post on other sites if I can not get information here. Would that be a better approach?

Well, I am sorry, you cannot discuss or take helpful advice. It was never my intention to flame you, as you have obviously done.

And, I believe you did state there is a bug\problem in Realtemp... Your words not mine:

Since the discrepancy in temp is with Real Temp I assume the problem is with Real Temp.

Also, I am not very good at mind reading; so, how was I to know you tested with other apps and that you did not want to dirty your registry again.

I figured we had an equivalent CPU and would test a few programs side - by -side and share the results. Sorry, it upset you.

I will be sure to not give any advise or help to you in the future... as you have 35 years of IT experience.

Try to Have a Happy New Year.

But, I would like to Thank unclewebb and newtekie1 for their help at explaining some of the information.

And, I have no idea where my attachment (png of the four monitoring programs running) got off to.

 

[Arctucas]

@unclewebb,

My sincerest apologies, the quote I was attributing to you was actually made by btarunr;
"AIDA64 has a much longer update interval than RealTemp".

Again, my apologies.

 

[unclewebb]

No problems Arctucas. It must have been the JD talking.
Happy holidays.

Just to clarify one thing before moving on. Two different users can have the exact same CPU and the exact same motherboards and everything else for that matter. The problem is that for whatever reason, one motherboard bios can hand off control to Windows and arrange the cores and threads in one order while the same bios can arrange the cores and threads in a different order before giving control to Windows. I have no idea why this happens. It rarely seems to be an issue with recent motherboards but it can happen with any motherboard, Core 2 or Core i7/i5.

When this is not an issue, two programs like RealTemp and Core Temp can report the temperatures in the exact same order whereas the next day, by random chance, these two programs might report the core temperatures in a completely different order. RealTemp will always be consistent and report the temperatures in the correct physical order but many other monitoring programs ignore APIC ID information. When APIC ID is not sequentially ordered (0123) in the RealTemp settings window, it becomes impossible to do the normal comparison of my computer does this so yours should be the same.

Here's what was happening on my friend rge's X58 board.



Most software assumes that the CPU is arranged,
core 0, thread 0 thread 1
core 1, thread 0 thread 1
core 2, thread 0 thread 1
core 3, thread 0 thread 1

so that the APIC ID order would show up in RealTemp as 01234567.

Look at the first screen shot that shows an APIC ID order of 06243571. This shows that the 4 main threads come first and then the 4 hyper threads come after but the main threads are in a different order than the hyper threads.

The two most common orders are 01234567 and 02461357. If software reads data from every second thread, in the first example, everything will be fine and it will report temperature data from each of the 4 cores. In the second example, if it uses the same every other thread algorithm, it will report temperature data from core 0 thread 0 and then thread 4 belongs to core 2 so it will report that and then it will report thread 1 which also belongs to core 0 and then it will report thread 5 which belongs to core 2.

0202

The result is that core 0 is reported twice and core 2 is reported twice and core 1 and core 3 are not reported at all. A user believes he is monitoring all 4 cores of his CPU but because the software they are using is ignoring APIC ID information, their monitoring software is really only reporting 2 of their 4 cores. When the APIC ID order gets really screwy as in rge's example, there will be times when only two unique cores are reported, sometimes 3, sometimes 4 and it's anyone's guess what order any of this data will be in. Not to pick on the competition but Everest had this bug for the longest time and I have no idea if it was ever fixed.

There's everything you ever wanted to know about an obscure Windows bug but were afraid to ask.

Thanks to rge's infinite testing, I realized that it is best not to assume anything about how the cores and threads are ordered. Only Core 0 Thread 0 is consistent. After that it is random chance. RealTemp 2.90 had this APIC ID bug but the recent versions of RealTemp handle this without any problems.

 

[N9ZN-Extra]

With the most recent bios, I haven't seen this issue for a long, long time.

I have a current BIOS and have the problem APIC ID. I do not know which motherboard or BIOS you have.

I do not know if this is comparing apples with oranges or EVGA 790I Ultra SLI motherboard BIOS with EVGA 790I Ultra SLI motherboard BIOS.

If you happen to have that board I am seeing this problem with the most current release of the BIOS. This is no big break through but I thought you might like to see this.

 

[unclewebb]

I'm using a totally different board. The point I was trying to make is that this mixed up APIC ID order can happen to any board with any bios version. On my board, the APIC ID order would randomly change from one boot to the next. It would just randomly change one day and months later it would change back to the more typical 0123 order.

For some of the newer CPUs that have hyper-threading, this could be a potential problem for software that ignores APIC ID. On a Core i7, the first two threads usually both belong to core 0 but it's possible that the first two threads could belong to two totally different cores. Some multi-threaded software locks tasks to specific cores so the CPU can't schedule these tasks on any available core. If it doesn't first check the APIC ID order, it may not accomplish what it was trying to do. Running two threads on two different cores usually gives you better performance than trying to run two threads on the same core at the same time.

On your Core 2 Quad CPU that doesn't support hyper-threading, it doesn't seem to matter that much. It's just a bug and most software has decided to ignore this. With RealTemp I didn't have the option to ignore this bug. With adjustable TJMax for individual cores and adjustable calibration factors, I had to make sure that RealTemp knew which core was which or else a users calibration settings would end up getting applied to the wrong core whenever the bios was having a bad day and using a different APIC ID order.

 

[N9ZN-Extra]

I'm using a totally different board. The point I was trying to make is that this mixed up APIC ID order can happen to any board with any bios version. On my board, the APIC ID order would randomly change from one boot to the next. It would just randomly change one day and months later it would change back to the more typical 0123 order.

For some of the newer CPUs that have hyper-threading, this could be a potential problem for software that ignores APIC ID. On a Core i7, the first two threads usually both belong to core 0 but it's possible that the first two threads could belong to two totally different cores. Some multi-threaded software locks tasks to specific cores so the CPU can't schedule these tasks on any available core. If it doesn't first check the APIC ID order, it may not accomplish what it was trying to do. Running two threads on two different cores usually gives you better performance than trying to run two threads on the same core at the same time.

On your Core 2 Quad CPU that doesn't support hyper-threading, it doesn't seem to matter that much. It's just a bug and most software has decided to ignore this. With RealTemp I didn't have the option to ignore this bug. With adjustable TJMax for individual cores and adjustable calibration factors, I had to make sure that RealTemp knew which core was which or else a users calibration settings would end up getting applied to the wrong core whenever the bios was having a bad day and using a different APIC ID order.

I understand the point now that I have had some quiet reading time. I am glad I went back to re-read things. The first time I went through you post I somehow went back to nearly my initial way of seeing things. That is why my suggestion made no since and YES IT MADE NO SINCE AT ALL. So I am glad your not doing that. For some reason this simple thing had me very confused. Now I understand you display the APIC ID as information and that the core temp data is reading left to right 0 to 3.

What I am concerned about now is why my processor is so far apart, during the Prime 10 minutes test, with core 0 and core 1 temps. I really don't know what to think of that. To understand it I guess it will take going back to documentation but I don't remember seeing the doc mention anything except core 0 and 1 should closely align.

Strange that my cores closest in value during the 10 minute test are core 1 and 3, they are nearly identical.

I wonder if a bios clear might clean the APIC ID up? Have you ever tried that?

 

[unclewebb]

Go back and read the part about these sensors are crap and were never designed to be used for accurate core temperature monitoring. Don't worry about the difference you are seeing. 99 times out of 100 it is a sign of sensor error and that's all.

If Intel used grade A sensors, all 4 cores would report the exact same temperature while running Prime95 Small FFTs. The cores and sensors are so close together that it's very difficult for a significant temperature gradient to exist when all 4 cores are equally loaded. If one core is running hot, that heat gets transferred to the core beside it so they both end up running at the exact same temperature. Use the core temperature data to guide you but don't ever treat it like it is 100% accurate because it is not.

I've never tried a bios clear to try and correct an APIC ID issue.

 

[oily_17]

Go back and read the part about these sensors are crap and were never designed to be used for accurate core temperature monitoring. Don't worry about the difference you are seeing. 99 times out of 100 it is a sign of sensor error and that's all.

If Intel used grade A sensors, all 4 cores would report the exact same temperature while running Prime95 Small FFTs. The cores and sensors are so close together that it's very difficult for a significant temperature gradient to exist when all 4 cores are equally loaded. If one core is running hot, that heat gets transferred to the core beside it so they both end up running at the exact same temperature. Use the core temperature data to guide you but don't ever treat it like it is 100% accurate because it is not.

I've never tried a bios clear to try and correct an APIC ID issue.

I think the bolded bits sum up this "bug", I have always seen a ~10C difference in cores on my 45nm Core 2 CPUs.

Nothing to worry about ,just keep your OC stable and you should be OK.

 

[N9ZN-Extra]

Go back and read the part about these sensors are crap and were never designed to be used for accurate core temperature monitoring. Don't worry about the difference you are seeing. 99 times out of 100 it is a sign of sensor error and that's all.

If Intel used grade A sensors, all 4 cores would report the exact same temperature while running Prime95 Small FFTs. The cores and sensors are so close together that it's very difficult for a significant temperature gradient to exist when all 4 cores are equally loaded. If one core is running hot, that heat gets transferred to the core beside it so they both end up running at the exact same temperature. Use the core temperature data to guide you but don't ever treat it like it is 100% accurate because it is not.

I've never tried a bios clear to try and correct an APIC ID issue.

Great, that will give me something to try.

I feel like a BIOS reset would not hurt anyway.

I don't mind loading the BIOS values back especially since some serious power issues I had with a PC build from a high end well known vendor. They left my PC without enough current to my GPUs for over 3 years until it was obsolete.

My expectations are not very high on this but I can kill 2 birds with one stone If this fixes the APIC ID order. That would solve a problem many people must be having. Considering your thoughts on some program threads not working along with other issues it could make for a crowd of happy users!

If the BIOS reset works you will be the first to know. I will also notify you if it does not work.

I think the bolded bits sum up this "bug", I have always seen a ~10C difference in cores on my 45nm Core 2 CPUs.

Nothing to worry about ,just keep your OC stable and you should be OK.

I never did expect to run anything all the way up to the cutoff temps (what ever it is). I will stop testing around 80C-85C which would give me an error of 15C-20C to compensate for most sensor errors. The plan is to not have the PC not running at those high temps and to watch it during stability and stress testing.

Great work gentlemen, this has been far more revealing than I ever expected. It is a nice piece of work on UncleWebbs part for any and all who seek out this thread for information. I learned a lot in the process which I am hugely greatful for.

 

[unclewebb]

The important numbers to remember in the majority of Intel CPUs is the thermal throttling temperature which occurs at approximately 100C and then the thermal shut down temperature isn't until 125C. Intel CPUs do a great job of managing themselves. Most of the Core 2 mobile CPUs and some of the new Core i chips have these limits set to 105C and 130C respectively. Even if something extreme happens like your CPU fan fails, your CPU will be able to continue running just fine without burning itself up. It might slow down but that's about it. The throttling algorithm works so well that it is usually enough to keep the CPU from ever getting anywhere near the shutdown temperature. Intel gives you plenty of time to correct the problem and to be able to save whatever you're working on if at all possible. You pretty much need the heatsink to become loose for the temperatures to reach the shutdown level.

Happy testing. Once you learn how durable these CPUs are, you'll understand why Intel didn't spend the extra money on sensors accurate enough to be used for temperature monitoring. The core temperature is not information that the majority of users need to be concerned about. It's just a number. Don't tell anyone or else they'll stop downloading RealTemp.

 

[burebista]

The important numbers to remember in the majority of Intel CPUs is the thermal throttling temperature which occurs at approximately 100C and then the thermal shut down temperature isn't until 125C.

Hehe Kevin remember this screenshot?

 

[mumak]

Hah, that's what I already tried to explain on [XS] few years ago, but no one listened. All have been keen on improving the reporting, playing with thermometers and various experiments.
Those sensors were never meant for temperature monitoring (rather catching the critical temp). They tried to improve the accuracy on Nehalem, but again screwed it up on Gulftown.
I published few accuracy numbers here:
http://www.hwinfo.com/forum/viewtopic.php?f=7&t=97
The things I publish are not my assumptions, it's official data from direct sources..

Go back and read the part about these sensors are crap and were never designed to be used for accurate core temperature monitoring. Don't worry about the difference you are seeing. 99 times out of 100 it is a sign of sensor error and that's all.

If Intel used grade A sensors, all 4 cores would report the exact same temperature while running Prime95 Small FFTs. The cores and sensors are so close together that it's very difficult for a significant temperature gradient to exist when all 4 cores are equally loaded. If one core is running hot, that heat gets transferred to the core beside it so they both end up running at the exact same temperature. Use the core temperature data to guide you but don't ever treat it like it is 100% accurate because it is not.

I've never tried a bios clear to try and correct an APIC ID issue.

 

[burebista]

mumak do you see something wrong here?

 

[unclewebb]

Core i CPUs are very dynamic when lightly loaded. Different programs have decided to use different methods to try and report more consistent looking data. RealTemp tries to closely follow the method recommended by Intel in their November 2008 turbo white paper.