N9ZN-Extra

My example above was an attempt to explain why I personally might desire to disable a core. As for the logic of it all I will be the first to tell you I do not trust Intels ability to shut down a processor prior to damage as is the case with many other users. Right or wrong this is why I would take an action as described. I understand how one bad core will affect all the others in the package and is exactly why I would want to shut a bad core down manually if it were exhibiting temperature values to high for personal comfort under load. Regardless of my logic and understanding I see why this is NOT A BUG in AIDA64 or Real Temp. It is aparrent that AIDA64 is reading values as you should be expected to read them and that Real Temp has tried to correct the presentation of information caused by the abnormal ordering of the logical cores within APIC ID. It looks like both of you are right on this issue, depending on personal viewpoint, and any correction in temperature presentation is clearly no ones responsibility when the root of the problem lies elsewhere. That decision to make a correction now seems more of an internal debate of each softwares author as to how they will procede. There are good arguments to be made for both paths of action. (I can see how this could be compared to painting path lines and placing a walk signal at an intersection where pedestrians were expected not to cross and how that placement would encourage abnormal expectations, clutter the intersection, and provide a safer walk across for those few who go where they should not. Leaving the question, do you decide on safetys side or promoting whats right?) Firey, you have done what I thought you might which is to offer as good of an explination as capability and information permits. This is one of the reasons I love AIDA64 and the scope of insight it provides. It is a better than good product. AIDA64 is well managed, organized, and coded. I will continue to re-new AIDA64 into the future and I see no other software even close to AIDA64's capability in the market. Thank you for your time, my understanding has improved as a result of this. In fact I have learned things I did not initially set out to learn because of your dedication to your users.

Unless I am misreading something it appears that your position and Real Temps position on temperature accuracy are inline with each other. I have no problem accepting that Intel had no reason to produce accurate temps from the sensors they have deployed and fully understand why they are not concerned about the in accuracies. It has become obvious they only need enough information to drive the formulas which control and shutdown the CPU under excess heating conditions. What does trouble me is the fact that my cores are not reported in the correct sequence and in my case why core 1 (actually core 3) seems to be lower. Is it temp inaccuracy or something else? Lets assume I needed to shutdown a core in BIOS due to a problem with thermals under load. If I do not know which core is affected I cannot make an accurate decision to shut down the affected core. In this case if I shut down the wrong core I would be placing more stress on an already malfunctioning core by having eliminated a working core. This is one expamle of how this could affect my machine and I am sure there are other scenarios. If APIC ID re-ordering was unnecessary then why do we have an APIC ID value, I can see no useful purpose for a variable which serves no purpose. If this is a BUG in BIOS it would be good to be aware of it and try to understand why it occured. Did BIOS initiate the BUG or did something else set the re-ordered values? If you could point me in the right direction, I will take this topic up in that channel. This will be helped by knowing at which point APIC ID is set and in which part of the boot process it occurs. By chance do you happen to know why APIC ID was established? The establishment of a core re-ordering method implies a need to re-order core locations or that something is incapable of reading cores based on a natural order. Let me stress this is not about how Real Temp or AIDA64 calculate temperatures, I understand there are differences. This is about why my cores are reported out of order ie: core 3 reported as core 1, other cores are also swapped. This is not an attack on AIDA64, Real Temp, or any other software. It is only an attempt at getting to the truth concerning core temperature reporting and the effect if has on our PC's. I love AIDA64 and enjoy recommending it to others for use. I can certainly tell them there may be a BUG outside of AIDA64 which can cause inaccurate reporting. As a suggestion, so you do not have to re-code things, placing a note beside the temps affected or elsewhere letting users know of this would be a great way to caution them when viewing temperatures which may have been affected.

i would not expect much in the form of debate, or maybe I should say I do not expect much of a debate. As far as I am aware the discussion at Real Temp is over with all that could be said having been said (to my knowledge). I still would like to know why I see my temps out of order in AIDA64, meaning why did APIC ID rearange my core positions? There is a question I need to pose to Firey and maybe he can give me some guidance as to who to speak to next.

So you will have input from the other side I am provoding a link to the thread where this was discussed with Real Temp. I myself am simply a user trying to understand what went wrong and why. If this is in error an explination of such would be greatly appreciated and certainly would promote my understanding. From what I have understood thus far the issue seem to lie with an area know as APIC ID and the core assignments within. As I understand things has nothing to do with the calculation method as much as it has everything to do with the core temperature which is being read and reported. The thread with Real Temp is here http://forums.techpowerup.com/showthread.php?t=137023 Please let me know if this logic is incorrect. I am very interested in knowing what I am looking at is valid.

Do you know if this will work with the G15 keyboard (first edition) with 18 programable keys?

aida64 temps.bmp Additional information: CE1 and SpeedStep are not enabled No turbo is enabled My processor is Intel QX9650 Extreme 45nm Quad core 3.0GHz Mother Board is EVGA 790I Ultra SLI Screen shots are attached: Unfortunately I could not post the RealTemp Screen Shot as the system would not allow it (sizeing issues). NOTE: THIS IS THE SECOND CPU CORE (core 1) I AM REFERING TO WHEN CORES ARE NUMBERED FROM 0 TO 3, IN THE SCREEN SHOT YOU HAVE THIS CORE LABELED AS CORE 2. AS A SUGGESTION STICKING WITH THE INDUSTRY CONVENTIONS OF LABELING THINGS LIKE CORES AND MEMORY BANKS WOULD BE HELPFUL WHEN TRYING TO DESCRIBE THESE KINDS OF ISSUES OR COMMUNICATING WITH OTHERS.

ON THE COMPUTER / SENSOR SCREEN I searched the forum and found no entries for this issue. While attempting to calibrate RealTemp to my processor temps I noticed that AIDA64 Version 1.20.1150 and RealTemp version 3.60 were in disagreement on the temperature of core 1 of my CPU. Core 1 is the second core of the CPU for clarification purposes. Please note no calibration has been applied to the Real Temp software at the time this was noticed, so you can rule that out. I do not know if this is an AIDA64 bug or not. If it is not an AIDA64 bug then it may be a RealTemp bug. Something I cannot determined at this time however all other CPU core temps are reporting correctly and correlating between AIDA64 and RealTemp. I also did notice that Core1 and Core2 temps seem to be changing at the same time to the same values consistantly. Any possibility AIDA64 software may be reporting core2 as core1?