# RealTemp BUG?



## N9ZN-Extra (Dec 24, 2010)

The values reported by Real Temp 3.60 differ with what I see in AIDA64 stable release 1.20.1150.

I am specifically referring to the value for CORE 1 (the second core of my quad core CPU). Real Temp is reporting temps for Core1 about 6 degrees Centigrate lower than Core 0. When i view this in AIDA64 I see both Core0 and Core1 at about the same temps.

Since the discrepancy in temp is with Real Temp I assume the problem is with Real Temp. In fairness I also submitted a BUG report to AIDA64 as well.

Maybe the two of you can work this out so I know what is going on with my processor.

I have a QX9650, no CE1, no Turbo, No SpeedStep, EVGA 790I Ultra SLI mobo.


----------



## 95Viper (Dec 24, 2010)

N9ZN-Extra said:


> The values reported by Real Temp 3.60 differ with what I see in AIDA64 stable release 1.20.1150.
> 
> I am specifically referring to the value for CORE 1 (the second core of my quad core CPU). Real Temp is reporting temps for Core1 about 6 degrees Centigrate lower than Core 0. When i view this in AIDA64 I see both Core0 and Core1 at about the same temps.
> 
> ...



IMO you should not really post there is a discrepancy in RealTemp and assume such before doing some thorough testing with other apps and such.


Core Temp, CPUID HWMonitor, Speccy and RealTemp 3.60 are all reading the same on my QX9650.
Don't know about Aida because I do not use it.
However, IMHO the apps I did test are so very close in results.  The degree of difference in the temps are negligible for software  monitoring apps. Just my opinion.

Maybe, the author of Realtemp can enlighten me, if I am faulty in my thoughts on this; and, help you.

View attachment 39703


----------



## N9ZN-Extra (Dec 24, 2010)

95Viper said:


> IMO you should not really post there is a discrepancy in RealTemp and assume such before doing some thorough testing with other apps and such.



*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?


----------



## mlee49 (Dec 24, 2010)

Does the program in question read the core temp exactly the same as Real Temp?


----------



## Arctucas (Dec 24, 2010)

I believe there may be a bug in AIDA64, but only with the Sensor page and not the OSD.

I just checked both AIDA64 and RealTemp 3.60.

I noticed that Core #1 would jump (momentarily) up to 46° in the Sensor page, while it would remain at 38° on the OSD. Core #2 would jump (again, only momentarily) to 42° on the Sensor page while the OSD and RealTemp reported 33°.

The other two cores temperatures matched up (both Sensor page and OSD) between AIDA64 and RealTemp.

Personally, I would use the OSD, I never did like using the Sensor page.

EDIT:

I forgot to mention that the AIDA64 OSD and RealTemp agree across all cores.


----------



## newtekie1 (Dec 25, 2010)

N9ZN-Extra said:


> *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 don't see how you can disagree with his idea that you should test with more than just two programs before claiming either one has a bug.  If two programs are giving different temperature results, then use a third or fourth to determine which is correct and wich is incorrect and _then_ submit the bug report.  Because while you are doing a good thing by submitting a bug report for the faulty program, you are doing a bad thing by submitting a bug report for the non-faulty program.  A false bug report is time the developer has to waste determining if the bug is legit or not.


----------



## N9ZN-Extra (Dec 25, 2010)

newtekie1 said:


> I don't see how you can disagree with his idea that you should test with more than just two programs before claiming either one has a bug.  If two programs are giving different temperature results, then use a third or fourth to determine which is correct and wich is incorrect and _then_ submit the bug report.  Because while you are doing a good thing by submitting a bug report for the faulty program, you are doing a bad thing by submitting a bug report for the non-faulty program.  A false bug report is time the developer has to waste determining if the bug is legit or not.



I am here for answers not for a distraction by those who wish to argue an insignificant point.


----------



## N9ZN-Extra (Dec 25, 2010)

mlee49 said:


> Does the program in question read the core temp exactly the same as Real Temp?



I would think it does, as far as I know there is only one sensor reporting that temp on the chip.


----------



## N9ZN-Extra (Dec 25, 2010)

Arctucas said:


> I believe there may be a bug in AIDA64, but only with the Sensor page and not the OSD.
> 
> I just checked both AIDA64 and RealTemp 3.60.
> 
> ...



Thank you for this information, it gives me a bsae line to look at so I can begin to determine what is going on between the two programs.

This is a great example of what I was looking for, feedback from others who have noticed a discrepancy between the results of the two readings. In a short while others will also have something relevant to say about the error unless they are being driven away by those who really are not assisting with issue.

It is good to know some of the community here is actually helpful. When I came here I did so believing I was not likely the only one who noticed this. If it turns out that I am the only one then I may have done someone a huge favor and may have saved a processor from frying if they are trusting an eroneous reading.

I am sure Santa will come see all of you regardless of how you feel about me.

Merry Christmas or Happy Holidays, which ever you prefer!


----------



## N9ZN-Extra (Dec 25, 2010)

Arctucas said:


> I believe there may be a bug in AIDA64, but only with the Sensor page and not the OSD.
> 
> I just checked both AIDA64 and RealTemp 3.60.
> 
> ...



I TOOK THIS COMPARATIVE SHOT OF ALL THREE SCREENS, AIDA64 SENSOR, REAL TEMP, AND AIDA64 OSD.

I am not seeing the same thing you are seeing. Take a look at my screen capture *ATTACHMENT* with all 3 running beside each other. Maybe we are not using the same release of the programs or there is a differance in the CPUs we are using.


----------



## mlee49 (Dec 25, 2010)

UncleWebb will be here soon(even though its a holiday), hopefully he'll have some answers for you.


----------



## N9ZN-Extra (Dec 25, 2010)

N9ZN-Extra said:


> I TOOK THIS COMPARATIVE SHOT OF ALL THREE SCREENS, AIDA64 SENSOR, REAL TEMP, AND AIDA64 OSD.
> 
> I am not seeing the same thing you are seeing. Take a look at my screen capture *ATTACHMENT* with all 3 running beside each other. Maybe we are not using the same release of the programs or there is a differance in the CPUs we are using.



Noticed I ran a prior version of Real Temp so I wanted to make sure we are looking at the right comparative versions of software. This attachment is using correct versions of all software.

The shot shows temps are not the same between sensor and OSD. It also shows a much larger swing between AIDA64 and Real Temp.

Both Real Temp and AIDA64 have excellent reputations for quality and this is pretty conclusive evidence something is wrong somewhere.


----------



## newtekie1 (Dec 25, 2010)

N9ZN-Extra said:


> I am here for answers not for a distraction by those who wish to argue an insignificant point.





N9ZN-Extra said:


> I would think it does, as far as I know there is only one sensor reporting that temp on the chip.



And yet you haven't taken either one of our advice and tested with a different program or two.

And no, there is a sensor per core, so 4 sensors per chip.  The sensors are reading how far away from TJmax the temp is, and the further away from the max the less accurate they are.

From your screen shot I don't really see the original issue you are complaining about.  The only thing I see is that RealTemp is reporting Core 0,1,2,3 and Aida reports Core 2,3,0,1.  Notice how the 4th core is reports significantly lower in Aida while the second core is reported lower in Realtemp.  I wouldn't be surprised if it is just the sensor inaccuracy.

Oh, and there is a reason that Realtemp gives you the option to adjust the TJmax.  Go into the settings and drop the TJmax 5°C and it bet Realtemp's temps line up better with Aida.  Not that it really matters, distance to TJmax is really what you want to know.


----------



## btarunr (Dec 25, 2010)

AIDA64 has a much longer update interval than RealTemp. Both apps update at different points in time. CPU temperature readings can rise and drop (±10°C) instantly, even in idle voltages.


----------



## N9ZN-Extra (Dec 25, 2010)

N9ZN-Extra said:


> I TOOK THIS COMPARATIVE SHOT OF ALL THREE SCREENS, AIDA64 SENSOR, REAL TEMP, AND AIDA64 OSD.
> 
> I am not seeing the same thing you are seeing. Take a look at my screen capture *ATTACHMENT* with all 3 running beside each other. Maybe we are not using the same release of the programs or there is a differance in the CPUs we are using.





newtekie1 said:


> And yet you haven't taken either one of our advice and tested with a different program or two.
> 
> And no, there is a sensor per core, so 4 sensors per chip.  The sensors are reading how far away from TJmax the temp is, and the further away from the max the less accurate they are.
> 
> From your screen shot I don't really see the original issue you are complaining about.  The only thing I see is that RealTemp is reporting Core 0,1,2,3 and Aida reports Core 2,3,0,1.  Notice how the 4th core is reports significantly lower in Aida while the second core is reported lower in Realtemp.  I wouldn't be surprised if it is just the sensor inaccuracy.



Don't get your 0,1,2,3 and 2,3,0,1 comment. They are all labeled as to which core is reported. All of the sensors are reading at 1 second intervals so I expect a slight deviation but not of several degrees. Like you said each core has a sensor and both programs are / should be reading the same sensors (we hope) for each core.

My initial observation and concern was the reading for CORE 1 which shows a deviation far to high even if read 1 second apart. Please remember the low temp deviation you refered to occurs at the sensor not in the program and the sensor has not changed between the programs.

Now about how loading makes a differance in reading accuracy. I fully understand the way linearity disperses at lower temps. I have seen the same temp relationships (differing by several degrees) with core 1 at full CPU load. For your information per Real Temps docs the sensors DO NOT REPORT TJmax any longer (Intel Changed that), you might want to change your terminology so you don't confuse someone else. I will let you look up the correct term as you think I should do with memory programs. What you do not understand sir, is that temp error occurs at the sensor and the sensor is read by both programs after the deviation occured. In other words the deviation in temps is static across the programs reporting the sensor temperature, in no way does that error vary between programs.

Let's do this, I can see this forum is very loyal to Real Temp and not to interested in a user with an issue. That should be of interest to at least a few who need temps as accurate as they can be. If it turns out that Real Temp has a program issue I promise not to come here to tell anyone. Then you will not have to bump your post count for nothing as you have just done.

On the Real Temp documentation pages people are invited to come to the forum for assistance. That is what I have done and thus far I am pretty dissatisfied with your attitude. The forum hit a high score of one out of 3 responding offering useful information.

Am I going to waste my time and my system space loading up temp monitors form all over the place to please you? Doubtful, and I will tell you AIDA64 invites BUG reports because they want to know of any issues they have so they can be fixed. This seems so not to be the case with Real Temp based on forum input but I will remember you are not the person coding this software and they indeed may feel differently.


----------



## unclewebb (Dec 25, 2010)

I know exactly what is going on.  Problem 1 is that RealTemp uses a TJMax value of 100C like all of the other Q9000 series of Intel CPUs use.  For some reason, some software uses a TJMax value of 95C for the QX9650.  I own a QX9650 and currently have it installed and all I can say is I disagree.

The second problem is that RealTemp is the only temperature monitoring software that organizes the reported core temperatures into their correct physical order.  Some motherboards have a bug where core 0 will always be reported in the correct physical order but after that, the next 3 cores can be arranged randomly.  If you open up the RealTemp Settings window, at the bottom you will see a value called APIC ID.  When that value is 0123, all monitoring software will report the cores in the same order.  When that is in a different order, most other software ignores that information so how they report the temperatures does not represent the physical core order of the CPU.

What RealTemp reports for core 0 comes from core 0, core 1 belongs to core 1, core 2 belongs to core 2 and the data RealTemp reports for core 3 is always coming from core 3, regardless of how screwed up the bios is.

When you are talking to AIDA about this issue, maybe you could also ask them why their software doesn't know what Super Low Frequency Mode (SLFM) is all about.





Either that or I've got the fastest T8100 on the planet.


----------



## N9ZN-Extra (Dec 25, 2010)

btarunr said:


> AIDA64 has a much longer update interval than RealTemp. Both apps update at different points in time. CPU temperature readings can rise and drop (±10°C) instantly, even in idle voltages.



Sorry I did not see this while writing my last post, your 2 out of 4 now.

I simply find it agravating to first be chastized instead of suggesting I try a few named programs to compare differances in temps. Followed by a flamer who only wants to throw more gas on the fire. If he is so worried about the developer wasting his time then he should go help the guy out. *These people just don't know how to speak with others, that is the problem.*

That was not what I came here for. Presently I am wasting my time and effort so I will go post about this on several other forums where I will get a responsive and helpful crowd.

Let's hope this is not a Real Temp bug. Even if temps can vary by 10 degrees in a flash I would not expect to see a consistent deviation in temps reported over multiple observations over multiple days of watching this. Every time I look at the temps that large fluctuation becomes less and less of a probability while an error in reporting becomes more and more evident.


----------



## unclewebb (Dec 25, 2010)

If you believe the information that Intel presented at their IDF forum, then the correct TJMax for a QX9650 is 95C.





I used to believe that before buying one and testing it with my IR thermometer.

If you believe that Intel was 100% honest then you have to also believe this information they released about the 65nm CPUs.





In my opinion, based on my testing, the TJMax value they originally released for the E6000 B2 is 20C too low.  When I started comparing and testing 45nm and 65nm CPUs with what they had said at their 2 IDF conferences, nothing made sense and nothing added up.  My complaints got back to Intel through the author at Tom's Hardware that did a story about this.  They were interested in why I thought their version wasn't accurate and I wasn't the only programmer that had some doubts.  I claimed 90C, Intel claimed 70C so a month later they split the difference and released some updated numbers and said they made a mistake in their original presentation and instead of 70C, they meant to say 80C.

It was at this point I decided not to believe a word they had to say about any of this.  It seemed to mostly be a smoke screen so users would stop asking, "What is TJMax?"

Think about their motivation.  The easiest way to make an expensive QX9650 run cooler is by lowering the TJMax value from 100C to 95C.  That gives the illusion that these CPUs run cooler than a regular quad.  Later in the fine print they used the term TJ Target.  That gets them around any complaints.  The TJ Target, according to Intel, is 95C for a QX9650 but actual TJMax might be 95C or it might be slightly higher.  Who knows?  For a high tech company, I found this "we're not really sure stuff" a little hard to believe.

During these presentations where they planned to reveal all about TJMax, there was never any engineering data presented.  Just some fancy charts full of data, some of which was so inaccurate that they had to re-release the information with new and improved numbers when the complaints came in.

Without a 100 or a 1000 QX9650 CPUs and an accurate lab, there's no way to prove this one way or the other.  The Core 2 based 45nm sensors that Intel used have so much error in them that any value could be correct so you might as well pick an actual TJMax value out of a hat.  Intel designed these sensors for thermal throttling and thermal shut down control and that's it.  Using them to report accurate core temperatures is not recommended.

Just for the record, this core ordering problem is also a bug in Windows.  Programs like the Task Manager also ignore the correct physical core order.  Other than RealTemp, I've yet to see any software read the APIC ID for each core and place the data in the correct order regardless of how the bios sets up the CPU APIC ID.


----------



## newtekie1 (Dec 25, 2010)

N9ZN-Extra said:


> Don't get your 0,1,2,3 and 2,3,0,1 comment. They are all labeled as to which core is reported. All of the sensors are reading at 1 second intervals so I expect a slight deviation but not of several degrees. Like you said each core has a sensor and both programs are / should be reading the same sensors (we hope) for each core.



As UncleWebb explained.  Aida is mixing up the cores.  What Realtemp is reading as core 1 is reported as the core 3 in Aida.  That is why Core 3 in Aida is so much lower while Core 1 is lower in Realtemp. You want to make a big deal and get rude about how we aren't concerned with your problem, but you aren't even paying attention to what we are saying.  You are worried about the difference in Core 0 and Core 1 in Realtemp, and you claim it isn't in Aida, but you completely ignored the difference between Core 2 and Core 3 in Aida.

And again, Aida is using a TJMax of 95°C and Realtemp is using 100°C.

And running CoreTemp, which requires no install, is hardly wasting system space.  And loading CoreTemp is wasting more time than complaining on the forum wasting about a bug that you yourself isn't willing to confirm is actually a bug?  Please...

I'm sorry you didn't like the answer to your problem, but I told you all the information you needed to explain what is happening.


----------



## unclewebb (Dec 25, 2010)

The APIC ID number in the RealTemp Settings window will tell you if Windows is seeing your cores in the correct order.  It should show 0123 as in this picture.






I can guarantee you that Windows is not seeing your cores in the correct physical order and will show a number different than that.  The APIC ID order will be consistent until the next time you reboot.  It can change from one boot to the next.  On my motherboard, it would be consistent for months and then for no reason, it would randomly change and be consistent again for months.  With the most recent bios, I haven't seen this issue for a long, long time.

In Visual C++, software uses the SetThreadAffinityMask() function to force code to run on different cores before reading the temperature sensor.  The problem with this function is that when you ask for core 1 or core 2 or core 3, your code may not end up on that core.  If RealTemp reports the APIC ID as 0213 for example, core 0 and core 3 will report correctly but the two center cores will be crossed.  When you ask for core 2 data you will end up getting the data for core 1 and when you ask for core 1 data, you will get data coming from core 2.  After you use SetThreadAffinityMask(), you need to query the APIC ID of the core your code is running on so you can be sure that your data is coming from the core that you think it is coming from.  RealTemp quietly corrects for this, other software does not.  

I first noticed this problem after flashing my bios.  Core 2 of my Q6600 always reported about 5C lower than the rest.  Suddenly after a bios flash, the coolest running core data was being reported as core 1.  It was as if the two center cores had changed positions which of course is impossible.  It took a while to figure this out because like I said, I tried other monitoring software and they all confirmed that my center two cores had swapped.  I also tried using the Task Manager and found it was bugged too.  That's when I started reading the Intel documentation about APIC ID and discovered the roots of this problem.  I'm glad you brought this up.  One of those RealTemp features that I never get any credit for.  There's a bug alright, but I made sure that this bug is not in RealTemp.


----------



## N9ZN-Extra (Dec 25, 2010)

newtekie1 said:


> As UncleWebb explained.  Aida is mixing up the cores.  What Realtemp is reading as core 1 is reported as the core 3 in Aida.  That is why Core 3 in Aida is so much lower while Core 1 is lower in Realtemp. You want to make a big deal and get rude about how we aren't concerned with your problem, but you aren't even paying attention to what we are saying.  You are worried about the difference in Core 0 and Core 1 in Realtemp, and you claim it isn't in Aida, but you completely ignored the difference between Core 2 and Core 3 in Aida.
> 
> And again, Aida is using a TJMax of 95°C and Realtemp is using 100°C.
> 
> ...


I have not decided yet if I will ignore you or take the time to lay things out line by line to show you why you did not give me the answer I needed to the question I ask. I would also explain to you why running a hand full of programs I don't have loaded on this PC would serve no purpose at all. What is stopping me right now are 2 questions; 1. Does the forum really need this? 2. Are you open minded enough to understand my response?

While I consider this I would say to you be careful with what you wish for. In the mean time you might think a little about how to address issues and interact with others.

The program author provided very good information, did it in a considerate way, and gave you an excellent example of how to interact in the forum. He would be a great mentor for you to follow.


----------



## N9ZN-Extra (Dec 25, 2010)

unclewebb said:


> The APIC ID number in the RealTemp Settings window will tell you if Windows is seeing your cores in the correct order.  It should show 0123 as in this picture.
> 
> http://img697.imageshack.us/img697/8307/apicid.png
> 
> ...



Thank you for the detailed information. Now I understand, from your perspective, why I see the discrepancy in temperatures between the two programs. It certainly would not surprise me if you were correct on your view of Intel and the data they put out. In fact I have a tendency to agree with you 100%, if that counts for anything, because I never had the need to understand the inner working of an Intel CPU. For my purpose if they run the programs and do not overheat that has been all I needed to know until this question came up.

Since you mentioned that a program could send data to a selected core and determine which core it is actually running on, I have a suggestion in the form of a question.

Do you believe it would be wise, in order to avoid confusion about the cores, to have Real Temp determine which core is actually being reported and arrange the output in the proper core order from 0 to 3 when outputting temperatures in Real Temp?

If you did this, some of the confusion I was having would not have come into play. The other part of my confusion was likely due to maximum temperature settings in Real Temp vs. AIDA64. I am not sure how the best way to handle that would be. What I was seeing in Real Temp (RT) was as you said, directly corelated to APIC ordering, unfortunately I can only find that information shown on the Real Temp settings screen with no description of what it means (other than in documentation I think). My point is to try to get RT output to display as other programs without confusing things more.

I will relay the questions you have mentioned to AIDA64. Seeing what they offer as a solution will be interesting and I have no way to know what they might choose to do, believe Intel, believe you, or get their hands dirty and find the answer themselves.

Thank you for your time, consideration, and clear understanding of the issue.

N9ZN-Extra


----------



## newtekie1 (Dec 25, 2010)

N9ZN-Extra said:


> I have not decided yet if I will ignore you or take the time to lay things out line by line to show you why you did not give me the answer I needed to the question I ask. I would also explain to you why running a hand full of programs I don't have loaded on this PC would serve no purpose at all. What is stopping me right now are 2 questions; 1. Does the forum really need this? 2. Are you open minded enough to understand my response?
> 
> While I consider this I would say to you be careful with what you wish for. In the mean time you might think a little about how to address issues and interact with others.
> 
> The program author provided very good information, did it in a considerate way, and gave you an excellent example of how to interact in the forum. He would be a great mentor for you to follow.



Again, I gave you the same answer UncleWebb did in a less technical detail.  The cores are out of order in Aida, Aida is showing the same temperature difference it is just labelling it on different cores, and Aida is using a lower TJmax.

I'm sorry I didn't respond with "it must be a bug" and so you didn't like the answer, but none the less it was correct.  And again, it takes less time to download and test with Speccy or CoreTemp then it does to come here and make all the posts you have made.  If you are not willing to take our suggestions to determine if it is a problem or not, why even post here?  Who is the close minded one here?  The people asking you to confim before posting about a bug, or the one that refuses to do anything to make sure it really is a bug?


----------



## unclewebb (Dec 25, 2010)

N9ZN-Extra said:


> Do you believe it would be wise, in order to avoid confusion about the cores, to have Real Temp determine which core is actually being reported and arrange the output in the proper core order from 0 to 3 when outputting temperatures in Real Temp?



That is exactly what RealTemp does.  It reports the core temperature data in the correct physical order.  Here is how the cores are laid out in a quad.

http://www.intel.com/pressroom/kits/quadcore/images/2006.int.qua.txt.EN.13x18.jpg

In this picture, Intel uses the numbering scheme 1, 2, 3, 4 but in C++ it is more common for sequences of numbers to start with 0 so I use 0, 1, 2, 3.  The data that RealTemp reports is always in this correct order.  It works around the Windows bug that ignores the correct order by reading the APIC ID information from each core.  That's what Intel recommends.  

By going the extra step like this, users of RealTemp will always be assured that the data is coming from the appropriate core.  Other software doesn't bother to correct for this bug so depending on the bios, you can run into situations where it seems that cores are moving around inside the CPU with core 1 being a cool running core one day and then for no reason, suddenly core 2 is the coolest running core the next day.  I think that looks dumb and most importantly, it is wrong.

I'm not sure if I understand your question but I would never change RealTemp so it reports the data incorrectly like all the other programs do.  I prefer to do things correctly which is probably one of the reasons why RealTemp has a loyal following.

It's the same with how CPU-Z is misreporting the multiplier on the newer Core i CPUs at idle.  It does this for consistent validation purposes but that doesn't mean what it is reporting is correct.  I could follow CPU-Z and do things incorrectly too but I'd rather tell users exactly what their CPU is up to.  When I confronted the programmer of CPU-Z with this information, here was his response.



cpuz said:


> Of course I admit that CPU-Z is not accurate anymore at idle on latest Intel generations, that is why TMonitor was developped.



As a user and as a programmer, I prefer software that is accurate.  I'm not going to be a Lemming and make my program just like all the other programs if they have chosen to report information that is wrong.  Even if 101 people claim that 2 + 2 = 5, I'm not going to follow along and agree.


----------



## N9ZN-Extra (Dec 26, 2010)

I am getting my self confused at this point.

I went and looked at your documentation again, and it tells me core 0 and core 1 should be close in values when the stress test is run. Based on your last post I see what you are saying and that would mean the values for my processor are far apart for core 0 and core 1. Does that mean the processor is defective?

Maybe I should just bundle the CPU, your documentation, this thread, and what ever AIDA64 tells me and send it off to Intel to see what they say, if anything at all.

What I first thought I understood is not what I am thinking now, that is what happens when distractions come into play adding to what already did not make since to me.

I do agree with you THERE IS CERTAINLY A BUG in some software.

All I really care about is not letting the processor fry, the ONLY THING which caused this discussion over the individual core temps was your documentation stating the core 0 and core 1 temps should be closely aligned when running the 10 minute test in Prime95. That was when I noticed the deviation in values between AIDA64 and RT reported temps for one specific core (what ever core it is). It was and still is that deviation I am not clear on which you may have told me the reason for it occuring. I am back to read yet again everything you have written and try to re-order my thinking.

When done with that if there are things I can document and discuss futher I will do so.

FYI when i suggested what I did I now believe I may have continued to not catch on to what you were telling me.


----------



## Arctucas (Dec 26, 2010)

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 (Dec 26, 2010)

Arctucas said:


> 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.
> 
> ...



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 (Dec 26, 2010)

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 (Dec 26, 2010)

N9ZN-Extra said:


> *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.
> 
> ...



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:



N9ZN-Extra said:


> 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 (Dec 26, 2010)

@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 (Dec 26, 2010)

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 (Dec 26, 2010)

unclewebb said:


> 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 (Dec 26, 2010)

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 (Dec 26, 2010)

unclewebb said:


> 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 (Dec 26, 2010)

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 (Dec 26, 2010)

unclewebb said:


> 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 (Dec 27, 2010)

unclewebb said:


> 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.



oily_17 said:


> 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 (Dec 27, 2010)

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 (Dec 27, 2010)

unclewebb said:


> 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 (Jan 5, 2011)

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..



unclewebb said:


> 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 (Jan 16, 2011)

*mumak* do you see something wrong here?


----------



## unclewebb (Jan 16, 2011)

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.


----------

