Printable View
Here's one for Unclewebb or anyone else who can enlighten me.
System is per sig with the addition of TEC cooling. Real Temp is reporting 11c on both cores at 4500 with 1.28125 vCore. The weird part is that Everest and speedfan show a cpu temp of 30c.
The core temps are the important ones but it is strange and I would love to know what is going on. Stuck sensor?
Edit: just took the system down to 3.33 with vCore of 1.000 the cores are still showing 11c and the cpu at 30c
This is just a guess but the 30c reading might be a board sensor at or around the socket that's not directly influenced by the TEC.
genec57: The sensor used to report CPU temperature is different than the sensors used to report core temperatures. I'm not sure what the lower limit is for the CPU temp sensor.
The core temperature sensors have a theoretical lower limit of -27C but I've yet to see one get this low without getting stuck. Intel has told us that some of these sensors might start to "bottom out" up around 50C. If yours get down to 11C then you're doing better than most.
The bottom line is that I don't think any of these sensors are going to give you accurate temperature readings when using a TEC. When you were using just water did you calibrate RealTemp and were you able to get some reasonable looking idle and load temps?
Under water alone the core temps were almost always the same and were quite believable under both load and idle. Now, the cores are reasonable under load.
For a while yesterday (first day under TEC) the cpu reported -2c then up then down and now it wont go below 30 but will go up under load, always staying about 20c higher than the cores. The cores wont go below 11c but will go much higher under load.
That really just means I will have to adjust the trigger cpu temp to shutdown the system. I have speedfan set to shutdown at 70c which brings up a suggestion I have. I would love to see a high temp shutdown in real temp. Then I could use it for ALL monitoring.
Thanks,
Gene
Just a minor update so that the System Tray status gets saved on exit. The System Tray Current, Min, Max, Avg, Distance to TJMax options are saved in the INI file so you'll get to look at the same info next time you start up RealTemp.
The other minor change is to the XS Bench feature. I've changed it to use 2 megabytes of memory during the bench which should fit in the L2 cache of most processors. There's talk of the new E0 processors having increased cache latency so I thought a benchmark that easily fits inside and targets the L2 cache might give users a way to compare E8x00 C0 vs E0. Do this quick bench on a C0 and an E0 at the same multi and FSB and maybe it will tell us something. This simple bench has always been consistent and very repeatable so maybe it's capable of detecting an L2 cache latency issue with E0 if there is one.
http://www.fileden.com/files/2008/3/...alTempBeta.zip
genec57: I was afraid to allow RealTemp to run a .bat file when an alarm was triggered because I thought some anti-virus / anti-spyware type program would flag RealTemp as being dangerous and a threat to man kind. By using a .bat file, a user would have full control over what they want to happen when a high temp alarm is registered. You're the second person to ask for a high temp shut down feature for RealTemp so I'll move this to the top of the things to do list.
The lower point where the core temperature sensors "bottom out" or get stuck seems to stay at one consistent temperature. If your cores are getting stuck at 11C then they will very likely continue to do that for the life of your processor. I'll have to wait until winter to see if my E8400 still gets stuck at the same point. Canadian winters are an overclockers best friend. :)
I'm not sure what happened to your other CPU temp sensor. I've heard of freezing warts off but I didn't know you could freeze a sensor to death!
Thanks for the replies. The other CPU temp sensor isn't dead. Like the core sensors it is stuck at ~30 but it will go up under load.
I will look forward to the high temp shutdown feature. I really prefer to use and trust Realtemp so it will be great to be able to use it exclusively.
Thanks again,
Gene
That's all the motivation I need! :up:Quote:
Originally Posted by genec57
Thanks for the software. I wonder is it possible to have it setup for 8 core system? I tried it on Skulltrail but it reports only 4 sensors. Also I noticed that it reports about 5c different than Core Temp ... is that ok? Thanks again for your efforts!
http://softwareblogs.intel.com/author/taylor-kidd/
Great Intel blog about CPU power management, C and P states.
There is also a wish list going on there.
Enjoy reading.
It would be possible but it's not really high priority at the moment since very few users have a SkullTrail system. The easiest way for me would be to try and create a second version of RealTemp. Regular RealTemp could read cores0..3 and the second version could read cores 4..7 for you. Not a perfect solution but then I wouldn't have to worry about bloating up the main RT code to cover a system that is in the minority. If interested in that then let me know. It might take a couple of weeks to get around to it.Quote:
Originally Posted by spiro
When you report something like this I need to know the version of RealTemp and CoreTemp you're using as well as the processor you're using. Both programs have recently made some changes. With the latest versions of each program, 45nm processors should be using the same TjMax since Intel finally disclosed that information. For older 65nm processors, it's still a guessing game since two years after the fact, Intel still hasn't released any TjMax documentation for their Desktop processors. Post some more info and I will explain further.Quote:
Also I noticed that it reports about 5c different than Core Temp ... is that ok?
Here's the latest version of RealTemp:
http://www.fileden.com/files/2008/3/...alTempBeta.zip
Marios: Thanks for the link. With that being on the Intel website, I better read fast before all that information mysteriously disappears and Intel pretends that it never really existed!
Unclewebb,
A follow up to the stuck CPU sensor. I have found that when I am changing settings, particularly Vcore will come unstuck (dropping to about1c) for a while and then will revert back to its stick point of 30c.
Is this typical of a sticking sensor? My intuition says so but I have no experience on point. Right now it is at 0 and the cores are both at 11c.
both my sensors are stuck at 33 core0 and 28 core1 at idle once i put them under load they scale evenly. ive tried to calibrate them so theyre even at idle but under load they are way off
http://www.fileden.com/files/2008/3/...alTempBeta.zip
I've added the ability to run a file when the RealTemp alarm is triggered.
I haven't decided yet if I'm going to add a file picker into the Settings GUI or keep it hidden. At the moment you can try this feature out by adding a new line to the RealTemp.INI configuration settings file like this:
AlarmFile="C:\Program Files\IrfanView\i_view32.exe"
You can probably think of something better than running IrfanView when you're computer is getting ready to go nuclear! :eek:
The AlarmFile will only be run once when an alarm occurs. If you want RealTemp to run it again then you'll have to restart RealTemp. A person could also write a .bat file for an orderly shut down or whatever they want their computer to do during a high temp alarm. Any suggestions about improvements or additional options for this feature are appreciated.
I'm in the middle of adjusting the Start Minimized feature in RealTemp for better Vista x64 compatibility. If that part of RealTemp 2.78 is working worse than before in Vista then don't be surprised. It's a work in progress. If I can't make it better then I'll at least go back to the old way. Version 2.78 is for users that want the AlarmFile feature right NOW!
genec57: I know a little bit about sticking core digital thermal sensors but my experience with a sticking CPU sensor is the same as yours. Zilch!
With any sensor, if you know it is sticking, even sometimes, then you can't rely on it to give you accurate and usable information below that sticking point. The Intel on chip sensors are consistent and usually fine when the temperature goes above the "bottoming out" point.
Same goes for you radaja. The RealTemp calibration feature is not designed to give you usable information out of a stuck sensor. If the sensor isn't moving at low temps then low temperature information coming from this sensor is useless.
I might be able to understand your situation better if you send me some data. Turn on the RealTemp logging feature and set the interval to 1 second. Let your computer sit idle for a minute, then run Prime95 small FFTs for about 2 minutes and then stop that and return your computer to idle for a minute. Take the log file and either e-mail it to me at the address in the About... box of RealTemp or copy and PM it to me here at XS. I can't guarantee you any miracles but I've seen enough messed up data that I might be able to help. :)
Shutdown feature works great and definitely useful addition :up:
I have vasilios shutdownXP enforcer, free program that will do a hard (immediate) shutdown.
If anyone wants to use it, search bolded name, available at many sites. Install it (nothing runs in background, it only runs if activated to shut off pc). Add one line of code to realtemp ini file, exactly as below in bold (unless default install location has changed)
AlarmFile="C:\Program Files\Vasilios Applications\ShutdownXP Enforcer\Data\Shut.exe"
Set alarm temp in settings (I set mine to normal load temp to test). Works perfect!
Nice find rge.
I'll include a link in the RealTemp docs to Vasilios ShutdownXP Enforcer v6.3
The start minimized feature is presently more broken than usual in Vista. Now that the alarm feature is more useful, I can get back to working on the start minimized issue that still effects many Vista users.
I took my Q6600 on water down to 1600mhz and 1.2v (couldn't figure out the 1.08v EIST thing...). I wasn't sure of the adjusted value. The read says 5*C for a dual, 6-7 for a quad. But I'm on water, but also my voltage is higher. I added 5*C to room temp. Is this right?
My adjustments were -4, -2, 2, -2. This made it 27*C across the board at ultraidle. Core0 and Core2 used to be 10*C apart, all the time, idle or lots of load. This doesn't really make sense. Now all my temps are within 4*C of each other during load. Is this more realistic, or am I fooling myself? I don't see how no matter the load two near-adjacent points are 10*C different, so this makes sense to me.
Overall load temps seem lower when compared to Core Temp, that's why I'm not sure if my +5*C over room temperature is right.
Great program either way!
EDIT first two cores are still hotter during load, which leads me to believe it's possible that my sensors were poor just like all of them BUT that I still have a realistic difference between the quality of the two dies.
EDIT and still a ~7*C max difference between different cores, which I can believe... but can't necessarily trust. Waiting for someone to call me out!
EDIT also forgot to say, the "sensor test" also waaaaay evened out, a perfect 3-3-3-3 at ultraidle, from something more like 1-7-4-you-get-it.
EDIT and now things make more sense, as Core2 used to be the coolest of cores but would also be one of the first to fail every time. Now it is one of the warmest cores...
@unclewebb thanks for the E-mail, i was running 450x9@4050 with 1.38v on my E8500.
AndrewZorn: I found this test kind of interesting on my Q6600 - G0:
http://img46.imageshack.us/img46/4435/balanceee1.jpg
Run Prime95 small FFTs and for "Number or torture test threads to run:" enter 3 instead of 4.
When your CPU is only at 75% load, it constantly moves that load around and it seems to be based on the data coming from the digital thermal sensors. I think when a process asks to run on any core then the CPU runs it on the core that is reporting that it is running the coolest. There are two Dual Cores within a Quad so I think the load is first split in half (more or less) and then those two loads are shared by core0 / core1 and by core2 / core3.
When uncorrected, my core2 always reports the highest Distance to TjMax value which means it is running the coolest so in this test it gets the biggest load and its partner, core3, gets to take it easy. The sensors on core0 / core1 always report very similar values so their half of the load is shared much more equally between those two cores. In both situations, the Distance to TjMax is being balanced for both sets of cores. In theory, Core i7 should be able to move the work load around and balance the temps between all 4 cores at the same time but the design of the Core 2 Duo seems to prevent this.
Task sharing by the CPU seems to be directly based on data from these temperature sensors. When you have a core reporting that it is running cool, it is going to get a bigger share of the work load. If in fact it tends to run at the same temperature as its partner but is misreporting its status, then it's going to be forced to run a bigger load which will make it run a little hotter than its partner. You can tell by looking at the graph that this balancing is going on constantly. Sensors that are not well balanced from the factory can lead to individual cores running at slightly different temperatures.
At higher temperatures where these sensors are much more accurate, the effect of the above declines and you will typically see core0 / core1 running at the exact same temperature and core2 / core3 also running at the exact same temperature. In most of the Q6600 screen shots I've seen, it's almost always core0 / core1 that report that they are running hotter. Typically about 0C to 5C which is shown in the above screen shot.
This might be just a sensor issue but it doesn't seem to be. Think about what would happen if during manufacturing that there was a slight difference between how the IHS contacted each set of cores within a Quad. It's possible that two of the cores might be making better contact with the IHS than the other two so the heat transfer is more efficient and they end up running cooler. Go try my test on your Quad and see what you get.
radaja: Your temps are great when running at that speed.
Have any of you guys tried out Intel Burn Test from this forum? It gets my Q6600 G0 super hot, I can easily get within a stone's throw from Tmax (100°C) depending on my OC and voltage. I wonder if my cooler (OCZ Vendetta 2) is not mounted well... Anyway I dialed down my voltages and OC so my core temps only reach ~82°C max just to be safe.
Intel Burn Test definitely creates some big heat, especially on a Quad. It's great to be Burn Test stable but if you don't ever use any software that ever gets your processor this hot then maybe it's a little overkill. I thought Prime small FFTs was a little overkill on most Quads compared to the temperature that most software runs at but Intel Burn Test is WAY overkill. I still like it and use it though! :)
Those results may be a bug in Prime95. It did the same thing when one core would fail. After I brought this up the issue was fixed in v25.6. Might want to ask over at the Mersenne.org forum for confirmation one way or the other.Quote:
Originally Posted by unclewebb
UncleWebb, that is actually very informative. I will try it when I get home!
However, I wasn't referring to the different dies being of different temperatures, as I see that even after the correction. What I mean is there is sometimes a 10*C difference between individual cores on the same die, even at super-duper-idle-near-room-temp or overkill load. After adjustment the values seem to "make sense" and I'm getting more of what you were explaining in the post.
I also wonder if +5*C over room temp is good for a Q6600 at 1.2v 1600mhz on good watercooling.
I was using version 25.6 in that screen shot. It's not a bug in Prime, just the way Quad core and Dual Core processors balance the load. The same thing happens when you have a Dual Core and run 1 instance of Prime. The CPU will constantly swap the task back and forth between cores to keep the cores balanced and core temperature seems to play a big part in that decision. This also happens when you run the typical single threaded game on a Quad. It doesn't run one core at 100%. It constantly spreads the work around so each core does part of the job so no one core gets over stressed.Quote:
Originally Posted by Praz
AndrewZorn: JohnZS may not have the record but his 45nm Quad certainly ranks highly when it comes to unbalanced sensors. On the same die he had a difference of 7 between core2 and core3 and the difference was 15 between the two dies when comparing core1 and core2. When you pull out the ruler and measure the number of millimeters between sensors, it becomes obvious that something isn't quite right.
Intel showed us that their 45nm sensors suffer from slope error where the further you get from their calibration point, the bigger the error can become. If you have one sensor that reads too high and one that reads too low on the same die then the combined error can be quite significant.
http://img187.imageshack.us/img187/9272/dtstemppu4.png
Intel did not get specific about what temperature they calibrate at but the example in the graph shows how slope error grows as temps decrease.
In my experience, most of the 65nm CPUs I've seen have had sensors on the same die that were either both too high or both too low. The 45nm Quad processors, especially some Extreme CPUs, can have both high and low reading sensors on the same die.
65nm sensors can also bottom out or get stuck at lower temperatures but this seems to be much rarer and at far cooler temperatures than some of the 45nm sensors get stuck at.
If you are water cooled then you need to be comparing your Ultra-Idle reported temperatures to your water temperature. (I like the term Ultra-Idle for low MHz / low volts.) Is there any way for you to manually set your core voltage lower in the bios? Try that and enable C1E or lock your multi to 6.0 when testing if your computer doesn't complain. My Asus boots up fine but some boards don't like to boot up when locked to 6.0x
I think a Q6600 being 5C or 6C above your water temp during this test is pretty reasonable. Open your case up and send me a log file at a 1 second interval of running 1 minute idle, 2 minutes of Prime small FFTs on all cores followed by 1 minute of idle. That helps me understand your processor better than just seeing a single screen shot.
You may very well be correct. However, there should be no difference between selecting three cores or Prime running on three cores because the fourth failed. With v25.6 when one core fails the load drops to zero on the failed core and the remaining three stay at 100%. Previous to v25.6 a failed core resulted in the same behavior you are seeing with selected cores.Quote:
Originally Posted by unclewebb
Uncleweb, do you have any plans to try embedding a thermo coupler into the IHS (or maybe a HS base) based on this info?Quote:
Originally Posted by rge