1. Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

RealTemp BUG?

Discussion in 'RealTemp' started by N9ZN-Extra, Dec 24, 2010.

  1. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     
  2. 95Viper

    95Viper

    Joined:
    Oct 12, 2008
    Messages:
    4,455 (1.96/day)
    Thanks Received:
    1,629
    Location:
    στο άλφα έως ωμέγα
    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
    [​IMG]
     
    Last edited: Dec 26, 2010
  3. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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?
     
  4. mlee49

    mlee49

    Joined:
    Dec 27, 2007
    Messages:
    8,497 (3.32/day)
    Thanks Received:
    2,107
    Does the program in question read the core temp exactly the same as Real Temp?
     
    dank1983man420 says thanks.
  5. Arctucas

    Arctucas

    Joined:
    Jul 14, 2006
    Messages:
    1,785 (0.58/day)
    Thanks Received:
    299
    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.
     
    Last edited: Dec 25, 2010
    dank1983man420 says thanks.
  6. newtekie1

    newtekie1 Semi-Retired Folder

    Joined:
    Nov 22, 2005
    Messages:
    20,255 (6.10/day)
    Thanks Received:
    6,293
    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.
     
    95Viper and dank1983man420 say thanks.
    Crunching for Team TPU 50 Million points folded for TPU
  7. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    I am here for answers not for a distraction by those who wish to argue an insignificant point.
     
  8. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    I would think it does, as far as I know there is only one sensor reporting that temp on the chip.
     
  9. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.:toast:

    Merry Christmas or Happy Holidays, which ever you prefer!
     
  10. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     

    Attached Files:

  11. mlee49

    mlee49

    Joined:
    Dec 27, 2007
    Messages:
    8,497 (3.32/day)
    Thanks Received:
    2,107
    UncleWebb will be here soon(even though its a holiday), hopefully he'll have some answers for you. :)
     
    dank1983man420 says thanks.
  12. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     

    Attached Files:

  13. newtekie1

    newtekie1 Semi-Retired Folder

    Joined:
    Nov 22, 2005
    Messages:
    20,255 (6.10/day)
    Thanks Received:
    6,293
    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.
     
    dank1983man420 says thanks.
    Crunching for Team TPU 50 Million points folded for TPU
  14. btarunr

    btarunr Editor & Senior Moderator Staff Member

    Joined:
    Oct 9, 2007
    Messages:
    28,972 (10.99/day)
    Thanks Received:
    13,759
    Location:
    Hyderabad, India
    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.
     
    dank1983man420 says thanks.
  15. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     
    Last edited: Dec 25, 2010
  16. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    968 (0.40/day)
    Thanks Received:
    430
    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.

    [​IMG]

    Either that or I've got the fastest T8100 on the planet. :)
     
    95Viper, mlee49 and dank1983man420 say thanks.
  17. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     
  18. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    968 (0.40/day)
    Thanks Received:
    430
    If you believe the information that Intel presented at their IDF forum, then the correct TJMax for a QX9650 is 95C.

    [​IMG]

    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.

    [​IMG]

    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.
     
    Last edited: Dec 25, 2010
    95Viper says thanks.
  19. newtekie1

    newtekie1 Semi-Retired Folder

    Joined:
    Nov 22, 2005
    Messages:
    20,255 (6.10/day)
    Thanks Received:
    6,293
    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.
     
    Last edited: Dec 25, 2010
    95Viper says thanks.
    Crunching for Team TPU 50 Million points folded for TPU
  20. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    968 (0.40/day)
    Thanks Received:
    430
    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.

    [​IMG]

    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.
     
    Last edited: Dec 25, 2010
    95Viper says thanks.
  21. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     
  22. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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
     
    Last edited: Dec 25, 2010
    mlee49 says thanks.
  23. newtekie1

    newtekie1 Semi-Retired Folder

    Joined:
    Nov 22, 2005
    Messages:
    20,255 (6.10/day)
    Thanks Received:
    6,293
    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?
     
    Last edited: Dec 25, 2010
    Crunching for Team TPU 50 Million points folded for TPU
  24. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    968 (0.40/day)
    Thanks Received:
    430
    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.

    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.
     
    95Viper says thanks.
  25. N9ZN-Extra

    N9ZN-Extra New Member

    Joined:
    Dec 24, 2010
    Messages:
    23 (0.02/day)
    Thanks Received:
    1
    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.
     

    Attached Files:

    • APIC.jpg
      APIC.jpg
      File size:
      56.6 KB
      Views:
      173
    Last edited: Dec 26, 2010

Currently Active Users Viewing This Thread: 1 (0 members and 1 guest)

Share This Page