Printable View
Thanks msgclb. On my board, the new code gives more stable MHz readings than CPU-Z. There's a lot less wander after the decimal point. Hopefully Grandpa, WoZZeR999, deepsilver and others that were having trouble with the MHz that RealTemp displays can try this utility. RealTemp 2.60 has some serious MHz issues on laptops so I'm hoping to test and integrate this new code into RealTemp as soon as possible.
Did you want another setFSB stepping from 440 to 450?
Thanks WoZZeR999. The data you and Grandpa previously provided me has really helped me get this right this time. How do you like the stability of the readings with this code? They're almost too stable now!
Awesome job!
no problems here...Quote:
Originally Posted by unclewebb
http://i116.photobucket.com/albums/o...0_RealTemp.png
but there's a bit of a lag till RealTemp shows the right MHz
Thanks emoners. The new code is working 100% better on my wife's Dell T7200 laptop as well. I didn't realize that the timers in each core aren't in sync on the mobile chips like they are on my desktop core processor. RealTemp 2.60 was giving some ugly MHz results on her laptop.Quote:
Originally Posted by emoners
I should be able to improve the initial lag time but it takes time to accurately calculate MHz so a little bit of lag is a fact of life. It's presently about 2 seconds on my Q6600. If it's a lot longer than that for you then let me know.
Try starting up CPU-Z with a stop watch handy for comparison.
With the later CPU-z, it has that loading screen. It may do the initial calculation there, and it take a while to load.
Love it unc... thanks for the great work :D
:up:
Here's a quick update that should cut the initial lag in half.
http://www.fileden.com/files/2008/3/...alTemp_MHz.zip
Thanks loonym. Your board looks similar to my board. CPU-Z usually reports from 0.0 to 0.5 MHz higher. Do you have SetFSB installed? I just want to be sure that this code is compatible with SetFSB on a variety of boards. No need to overclock any further, just drop it down a couple of hundred MHz.
Has anyone found the frameless option yet?
http://img228.imageshack.us/img228/5...amelessln8.png
Would something about that size with the temps inside be a handy option for RealTemp?
Yeah, when I said to myself 'WTF, this is a button', then clicked it.
I personally wouldn't use the feature for what mhz it was running at on a regular basis. If you made it a pop-up around that size, and put the FSB/multi under the speed, that may be helpful for screen shots where you don't want cpu-z taking up half of the image.
Edit: I read you questions wrong. It may be easier to just have in your settings what you want to show, or combine min/max into 1 box with min_temp/max_temp. That way you can personalize what you want it to look like.
Settings screens could have something like below for options on what to show.
WoZZeR999: I like the check mark idea. Customizable software is always a good thing but I'm not sure how to program that at the moment. More stuff to learn.
I would keep a a visual of all of the options somewhere in the settings panel so that you don't have to keep the check boxes on the main window. Figuring out the window size shouldn't be a problem once you figure out how much space each box needs.
It's obviously harder than that, but it would be a nice feature to have in the future.
like this ?Quote:
Originally Posted by unclewebb
http://i26.tinypic.com/2ywehi8.jpg
WoZZeR999: I did some reading and your check mark option might not be too hard at all. I like the idea of going into the Settings window and checking off what you want to see. I'll throw it on the things to do list.
mariosimas: I thought that would be a good size that users could add anywhere when posting a screen shot. I might put the MHz label on it so it is clear what that number represents.
A mini option in realtemp? LOL I'd use it! And w/setfsb it's all spot on with both msi 780i and giga x48t, both with yorkfield quads.Quote:
Originally Posted by unclewebb
I sugest also one "always on top" option
@ unclewebb
Oh it's MHz? Thought it was the Star-Date :D
Cool, if I could have a compact window that had the correct temps, that would be awesome.
1 other thing that would be interesting, have it add a * after the temp (in the case of PROCHOT# not being used) in the 'Core temp' area. So if the flag was thrown, have it say 40C*. You could shoot that down is you didn't think it would be helpful, just a thought.
My reason for suggesting this isQuote:
Originally Posted by unclewebb
You say that at low temps, the DTS nbr is NOT accurate, so you provide a method to adjust this reading for low temps.
You also say that you adjust this based on some formula in your code.
So, if DTS at low temps is wrong, then the distance to TjMax is also wrong.
If your formula (after idle calibration) shows correct temps, then the distance to TjMax should reflect this.
Hope you understand my reason
martymonster: I understand your reasoning but I disagree with it.
The theory behind my program is not that the Distance to TjMax or reading from the Digital Thermal Sensors (DTS) is wrong. The problem is that other software has always assumed that this distance to TjMax moves linearly and that being a distance of 50 units away from TjMax is exactly the same as being 50 degrees away from TjMax. In my testing, that statement hasn't proven to be true.
That's why I use the term Distance. It more accurately reflects what the DTS is telling a user. A distance of 50 units away from TjMax on your processor might mean it is 45C or 50C or 55C or some other number away from TjMax. For this reason, DTS data is not comparable between two different processors.
The traditional formula has always been:
Reported Temps = TjMax - DTS
and when you rearrange the terms you found that:
TjMax = Reported Temps + DTS
This formula is wrong so RealTemp uses a modified version of it:
Reported Temps = TjMax - DTS + CorrectionFactor
With my formula, TjMax = Reported Temps + DTS
will only be true when you are not using a CorrectionFactor or at higher temperatures when the CorrectionFactor is equal to zero.
The bottom line is that what RealTemp reports as Distance to TjMax is simply the raw data being read from the processor which can be directly compared to other programs like CoreTemp that also report this same data. RealTemp's interpretation and conversion of this data into an absolute temperature may be different than other programs but there's no way I'll ever change the reporting of the raw data so the numbers add up nicely in a formula that isn't correct across the entire temperature range of these processors.
Edit: The new MHz code has been added to RealTemp without any issues. I did some house cleaning and added the toggle button back to the upper right portion of the screen so VID will be updated in real time again and I also added a clock in there that keeps track of how long RealTemp has been running for. It should stop when you go into Stand By or Hibernate mode and resume running when you resume. This will make it much easier to determine how much time was spent on the 'puter, ahhh working. :D
RealTemp beta testing should resume tomorrow and hopefully it will be a little easier on Vista compared to 2.60.
http://img135.imageshack.us/img135/6233/rt261oc8.th.png
keep the good work :up::up::up:Quote:
Originally Posted by unclewebb
Hi all,
I just stumbled across this thread and need some help.
I've followed the calibration instructions and taken my Q9450 down to a FSB of 266MHz and the core voltage to 1.104 (as reported by CPU-Z). The idle temps I see are basically the same as when I was using the stock FSB and voltage. For what its worth, I'm using a Thermalright Ultra-120 Extreme on a Gigabyte GA-X48-DQ6 in an Antec P182 case that's well cooled. Ambient is 72 F (22.2 C).
Here's what I see at idle (the first two are from Everest, the rest from Real Temp):
- Motherboard: 30
- CPU: 20 (note that this is 2C below ambient)
- Cores 1-4: 36 / 32 / 40 / 40
Note that cores 3 and 4 never register below 40 C but do seem to work normally above that.
When I run 4 copies of Prime95 with small FFT's, each copy tied to its own core, all of the core temps go to 46ish except Core 3 which stays at 40.
When I do the same with normal FSB and core voltage, I see the following after a few mins:
- Motherboard: 31 (from Everest)
- CPU: 36 (from Everest)
- Cores 1-4: 53 / 49 / 49 / 55 (these are max values)
When I stop Prime95, cores 1-3 drop very quickly while core 4 takes a while to get back to a typical temp.
All of this raises a few questions:
1) What should I set the Idle Temp Calibration factor settings to?
2) Obviously its impossible for the CPU to be 2 degrees below ambient, but assuming some reasonable amount of +/- in the sensor, is this value believable or is there something defective with the CPU temp sensor?
3) Why would the CPU and core temp values be so far apart?
4) Should I be concerned about core 3 and core 4 not registering below 40 C? They seem to be roughly in line with the other cores for temps above 40 C.
5) Can the motherboard BIOS revision play a role in this? I'm still using the original BIOS that came with my mobo. They've released a bunch of beta BIOS'es since then but no newer non-beta BIOS'es.
Bottom line: I've got 2 more days to return this CPU. Other than the temp readings I mentioned above, it seems to work normally. Do I return this one and try another or are these problems so minor and/or common that I'm *not* likely to do better with a replacement?
Many thanks in advance....
lunadesign: I'll try to answer your questions.
Your first reading of CPU at 20C shows a sensor that isn't 100% accurate at reporting low temperatures. This is a sensor on your motherboard so swapping CPUs won't change this reading. That inaccuracy is pretty typical for a motherboard sensor and is the original reason why Intel went to on chip sensors. If you know this sensor is not 100% accurate then making any further comparisons to what it's reporting is pointless.
In most documentation the cores in a Quad are numbered 0, 1, 2, 3. CPU-Z also uses this convention so I'll be doing the same when talking about your Quad.
Core2 and core3 sitting at 40C is typical for sensors that are getting stuck. Lots of sensors on the new 45nm chips do this at low temperatures but most work very well when the temperature goes above this point. Keep in mind that these sensors were neither designed nor calibrated by Intel to accurately report idle temperatures. If they work for that purpose, great but if not, Intel does not consider this a valid reason to return a processor.
The Calibration feature in RealTemp will only work on cores that are not getting stuck. With a stuck sensor, there's nothing you can do with it.
With two sensors that are likely stuck, you then have to look at the sensor in core0 and try to determine if it too is stuck. Sensors don't always stick at the same value for each core. Turn on the logging feature in RealTemp and set the interval to 1 second. What I look for is as your processor is cooling down after booting up, the temps should be dropping pretty much equally on core0 and core1. If you notice in the log that core0 is dropping at about the same pace as core1 and then it suddenly stops while core1 continues to drop further then that would be a good sign that core0 is stuck as well.
If they both move at about the same pace as your CPU cools but end up at slightly different values then something like that can be corrected by using slightly different calibration values for each core. For example, my Q6600 is pretty accurate when using these factors ( 1.0, 1.0, 2.2, 1.2 ) but every processor is unique.
Core1 might be your only reasonably accurate sensor. I've done all of my testing with an open case and if possible you should do the same. Core1 at 32C during my low volt/MHz test in a closed case at a room temperature of 22C is probably pretty close to the actual temperature. See if opening the case changes anything and if any of your readings drop another degree or two. Do some more testing and I'll try to come up with some calibration factors for you but there isn't anything that I can do if 3 of your 4 sensors are getting stuck at low temps. At least they seem to work at full load. At 50+C these sensors are usually within a degree or two of the real temperature so you shouldn't worry too much.
A different BIOS might change your CPU reading but it will not change the core temp readings that RealTemp reports. This data is being read directly from the on chip sensors within the Intel CPU.
I wouldn't bother returning it if it runs decently for you. Sadly, your sensors seem to be pretty typical for a 45nm Quad. :(
unclewebb - thanks for your response (and your neat program)....I really appreciate it.
Regarding the CPU temp that's reading 20C (Tcase), I thought this sensor was located on the case of the processor but read by the motherboard?
I opened the case, turned up the exhaust fans to max (they're Antec Tri-Cool fans) and underclocked/undervolted my system and the min temps are:
- CPU: 16 C (definitely not believable)
- Cores 0-3: 31 / 28 / 40 / 40
- Ambient: 23 C
If I run your "Test Sensors" test, Core0 and Core1 both bump up by about 4 C and come back equally fast. So, it looks like Core0 and Core1 are decent although slightly offset from each other.
Since my CPU sensor seems to be inaccurate, I guess I can use Core0 and Core1 as my reliable measuring sticks, right? And since Core2 and Core3 appear to become unstuck and roughly track the others when > 40 C, I guess I can trust all 4 in those circumstances? What would you recommend for calibration factors?
Are the temp sensors any better in the Xeon equivalent 45nm Quads? I'm just curious because I have to build a few more boxes like this one....
I'll have to check up on this. I thought it was reading a sensor that was located in the CPU socket but don't quote me on that.Quote:
Originally Posted by lunadesign
Looks like the sensors on core0 and core1 are both working fine. My best guess is that your actual core temperature is between 28C and 30C during your test. If you want to keep things simple you could assume 28C so you wouldn't need to do any calibration on core1 and then you could use a -1.0 calibration on core0 which should bring it down to 28C also. If you choose to go up a degree or two, that's fine. Just use calibration factors so core0 and core1 are balanced during this test. I like the simple approach where you only have to use one factor. When you return to your normal MHz, you might need to do a slight adjustment. Core0 and core1 should be pretty much equal at idle even when overclocked and overvolted.
I like using Prime95 v25.6 running small FFTs. Are you using a multi-core version of Prime or running 4 individual instances of Prime? I'm not sure if this would make any difference to your results. At full load I generally find that core0 and core1 are equal while core2 and core3 are equal but the two sets of cores might be off by a few degrees. One user I helped had load temps similar to yours where the two outside cores ran hotter than the two inside cores and I think when he re-did his thermal paste this changed. Anything like installation procedure or an IHS / heatsink that is not perfectly flat can cause slight differences at full load as well as less than perfect sensors. Probably not worth worrying too much about though.
The other test I use is to use Prime95 and to go into the task manager and set the affinity to limit it to run on 1, 2 or 3 of the 4 cores at a time and to switch the load around while Prime is running. If you get some interesting numbers then post them.
I don't believe the Xeon sensors are any different. The 45nm sensors just aren't always capable of giving us the information that we'd like to be able to get out of them. It's sort of random luck and I think you're doing better than most users have. At least you took the time and did your homework so you know exactly what your sensors are capable of and the temperature range where they give you accurate data.