Good Work Uncle
Mine is fixed, see Quad Core Order
http://i265.photobucket.com/albums/ii218/ozbyte/MSR.jpg
Printable View
Good Work Uncle
Mine is fixed, see Quad Core Order
http://i265.photobucket.com/albums/ii218/ozbyte/MSR.jpg
Thanks WizardofOz. This is an interesting bug that has never been talked about before. This evening I moved the reporting of this into the Settings window along with a toggle switch so you can turn this feature on or off. This will make it easier for users to keep an eye on things.
This bug has been screwing up the temperature reporting consistency of Quads since they first came out. It will be interesting to see what percentage of Quads have this random core swapping "feature." Maybe all of them do this if you own them long enough.
The test to make sure it really is working correctly is to run Prime95 and use Set Affinity... in the Task Manager and force it to run only on core0. It should be pretty clear when you do this what software is doing it right. :up:
I started noticing this problem when I installed HWMonitor. It shows the core order like your test program. My QX6700 is 0231 as well and it's listed the same way in HWM. I have noticed that the order changes at times. Am I to understand that RT will now show the cores in the correct order on the main page or do we correlate the core positions?
Opps, HWM shows 0312. They appear correlate with the proper temps for each core, just higher than RT.
Axis
I believe the core order only changes after a re-boot and RealTemp should be able to automatically adjust to whatever order pops up.
I just installed HWMonitor 1.09 but the problem I'm having is that it doesn't display my core temperatures. I'm pretty sure it used to but nothing today.
http://img511.imageshack.us/img511/2...monitorak9.png
The Winbond CPU temp reading has always been a little screwy and the 12 V is too high and the 5V is too low compared to a multimeter but I've learned to ignore this data.
I went to the File menu and clicked on Save and had a look at the file it created and it shows this:
Processor 0
-- Core 0
-- Thread 0
-- Core 2
-- Thread 0
-- Core 1
-- Thread 0
-- Core 3
-- Thread 0
I believe CPU-Z and HWMonitor both use the same software development kit so it looks like they are both handling this problem.
I think HWMonitor continues to use the wrong TjMax for the 45nm desktop processors so the reported temps might be a little higher than RealTemp and I guess we don't agree on TjMax for many of the 65nm processors either.
There may be different versions of this core ordering problem than I'm aware of or RealTemp might just label things differently. I'm still learning.
If you have any new information then post a screen shot of HWMonitor and what RealTemp shows for the core order and maybe even CoreTemp so we can see what the original data looks like. The more numbers the better!
Do this while running Prime95 on core0 only and I'll be really happy. :D
Edit: The next beta release will let users see this info in the Settings window so maybe more users will start to notice why their Quad temps get mixed up sometimes.
http://img181.imageshack.us/img181/1859/miscpp8.png
Edit #2: Good news. HWMonitor found a couple of cores on my Quad. Bad news, there's still two of them missing and now it can't find my graphics card that it found earlier today. If I make RealTemp work just like this program then I'm going to be in a lot of trouble from my friends at XS!
http://img128.imageshack.us/img128/4...orequadlt8.png
Hi UncleWebb : I cant seem to get ver 2.67.1 despite downloading it 4 times now. what i do get is 2.67 everytime with time/date 22:15 23/06/2008.
been following this thread for a while as i also have the mis-assigned core problem and used the links here to go from RT 2.5? to 2.67 step by step so i am familiar with setting up everything in a new folder each time and executing directly from within explorer to ensure i run the correct exe.
could you please post another link to latest version. thanks.
If you are using Firefox you need to clear your cache or instead of downloading the latest version it will find an old version in your cache and keep giving you that one. If you still have problems then send me a PM.
I did some more reading about core assignments in the Intel CPUID manual which surprisingly left out most of the important details. Luckily I found a second source of info. RealTemp 2.68 will be ready tomorrow which should handle every possible combination of problem. Even the ones that I haven't heard of or don't have any evidence of yet.
I'm using HWM 1.08.0 if that makes any difference. Rebooting DOES intiate the switch but it doesn't always switch. I guess it randomly switches upon reboot. What's also weird is that OCCT 2.0.0A uses the same software that HWM uses and OCCT shows core 1-2 within a degree and 3-4 the same which indicates that they arrange the cores together after the reading, much like you're now doing. HWM shows the temps on each core, which are correct, but they don't arrange them in order. As we both know Everest has the cores wrong.
Axis
Any chance of the font used for core temp and distance to TJ max getting changed to the the smaller font and allowing idle calibration to go to -4.0 or -5.0? -3.0 is not enough for my E7200, as it's DTS are "stuck" for low temps, they are about 10c off.
EDIT: Wow, first and last post here.
Download the beta here, unzip and copy the new RealTemp.exe into your previous RealTemp folder.
http://www.fileden.com/files/2008/3/...alTempBeta.zip
http://img108.imageshack.us/img108/3...temp268va4.png
If it doesn't download 2.68 then try a different browser and empty your cache.
RT2.68 will report your core order in the Settings window. The sometimes random core ordering is not really a Quad bug but it's something that software, especially temperature monitoring software, needs to be aware of and needs to correct for.
This issue is also not being dealt with by the Set Affinity... option in the Task Manager in Windows XP. Here's an example:
RealTemp reports 0 2 1 3 for the Core Order for my processor.
CPU 0: --> core0
CPU 1: --> core2
CPU 2: --> core1
CPU 3: --> core3
Here's what that table means. My processor is fine for core 0 and core 3. In TaskManager if I use SetAffinity... and tell it to put the load on CPU 1, it actually puts the load on core2. If I tell it to put the load on CPU 2, it puts the load on core1.
Software that doesn't deal with this issue is going to have a problem. When it uses the SetAffinity() function and asks for temperature data for CPU 1, my processor is crossed so it returns the temperature data for core2. By creating a lookup table like RealTemp now does, any request within RealTemp for temperature data should be getting that data from the correct core. That's the theory at least! :D
The only 3 core orders I've seen reported so far are:
0 1 2 3 ~ normal
0 2 1 3 ~ center cores crossed and
0 2 3 1 ~ maybe I'll call this one the core1 shuffle
In the last version, the temperature data for core1 gets shuffled to the end of the line so CoreTemp 0.99 and Everest will report your core1 data as Core #3.
If anyone sees something else pop up in the Core Order window in RealTemp then let me know. This code also works with Dual core CPUs but I think all of them will report 0 1. RT2.68 handles the 0 2 3 1 situation differently than RT2.67.2 but now that I've done my homework, I'm 99.9% sure that RT2.68 is finally getting this right. After each re-boot or start up, if your bios reorganizes your cores, RealTemp will automatically compensate and report them in the correct order.
shake hands and rip off the arm :)
Some really don't seem to understand how much devotion it takes to create such a handy program like yours and coretemp and on top of that keep it up to date... Top notch job mate
I still love your program if that matters.
When does the movable mini-window come in to play? After that, I don't think I could complain about anything else.
Definitely thinking about that one. I kind of know how to do it but I still haven't got around to it. Got a little side tracked as you can tell by my posts for the last week.
The GigaByte name is finally coming back to me. Three months ago I spoke with a GigaByte on a different forum and he told me that I was wrong, my testing was wrong and the stuff that rge has found and the Intel papers on this subject were also wrong. Now he'd like me to customize RealTemp for him. Very odd. If you want to see how our last conversation went then follow this thread.
http://www.overclock.net/3543745-post54.html
Back then, I went out of my way and did a thorough test on an E2160 and the results were as convincing as they come but he still wasn't buying into it.
Thanks Leeghoofd. Happy users motivate me to continue to improve RealTemp.
I'm using Firefox 3.0 on this E6750 computer and 2.68 downloaded properly. I can only hope my luck holds out.
This is one older person:D that could use that enhanced version as I need a new pair of glasses but that is a little over doing it.
I haven't tried this on my Q6600 as it hasn't had any problems yet.
I think if you checked Gig's palms you would find circular burns from the stove and paint on the fingertips,,,
Is it on? paint still wet?
unclewebb, hit & run critics seem to come with the turf. Regardless, in support of your efforts, check out the recommendation and link to Real Temp which I've included in the Introduction (Section 1) of my Core 2 Quad and Duo Temperature Guide: http://www.tomshardware.com/forum/22...perature-guide
A second reference and link also appears in Troubleshooting (Section 15).
Also, I realize that you have more than a full plate, however, I'd like to offer a suggestion that I don't recall being previously mentioned in this extensive novel. How would Real Temp users feel about having a temperature alarm feature?
Comp:cool:
Here's a configuration I haven't seen before: 0 1 3 2
http://members.cox.net/wifeometer/RT...ug_present.jpg
Hello !
Here are my results
Thanks for the :up: from everyone. The complaints during this project have been non-existent compared to the abuse I thought I was going to get. Writing core temperature software based on the limited Intel documentation is about as much fun as jumping into an alligator pit.
FullSky: The way I'm testing for this problem is going to result in a few new combinations in the Core Order box. I'm hoping that the end result will be as good as the previous version and hopefully better. If not, then I'll have to go back.
I will be working with zorzyk during the next few days who has a processor that has produced a few different combinations. We're going to try and come up with some definitive tests to prove if RT2.68 is getting his processor right.
perso: Why not include CPU-Z in your screen shot so I can see how RealTemp MHz compares. You could also try running Prime95 and use SetAffinity in the Task Manager to limit it to CPU 0. This will give me some feedback on how the core ordering recognition is working out.
unclewebb, what are your thoughts regarding a temperature alarm feature?
Comp:cool:
do these temps look odd?
http://farm4.static.flickr.com/3129/...7f16e640_o.jpg
They are like this on both my Asus P5E VM HDMI & abit IP35 Pro... BIOS is default everything for now.
also, what causes apps like these to display min vid vs max? just a min ago my vid was 1.2250... now it's 1.1500
those temps sensors look like they are misreporting (stuck?). I don't know, but does speedstep have a factor with VID?
lefy: You might want to try scrolling up a few posts and downloading the latest beta version of RealTemp.
http://www.xtremesystems.org/forums/...postcount=1559
It reports Min and Max VID. I know a T7200 mobile chip can have 4 different VID readings as it transitions from idle to full load. I've only seen two on Desktop chips but I think the transition happens extremely quickly that detecting more than that might be difficult.
The quality of 45nm sensors you end up with seems almost inversely proportional to how much you pay for your CPU. Probably just a coincidence. It's always good to keep in mind that Intel did not design or calibrate these sensors to accurately display idle temperatures. If you are one of the lucky ones and your temps are accurate at idle then consider that a bonus but if your idle temps are all over the place then that is considered normal. When you have no consistency it would be a good idea to try and do my low MHz / low voltage test as outlined in the docs to see if any or yours sensors can be relied on. As Shadowthor mentioned, sticking sensors is common in the 45nm chips at low temperatures.