8 degree diff in core temps

[JOhn Magee]

I'm using the i7 920 and RealTemp shows 35-28-34-27. Is this big a difference normal or do you think I may have done poorly applying the thermal paste (I hear that a thin layer is better than thick)
Thanks

[Easo]

Depends from processes using cores. Usually first core should be higher, since a lot of things still happen on first.

[unclewebb]

Most Core i7-920 CPUs have very consistent temperature sensors and your differences look more than usual. I usually draw a line or two of thermal past and then when installing the heatsink I rotate it slightly back and forth a little and let the heatsink do the spreading. Not an exact science but I get fairly consistent results. I tend to use a little more than recommended because I've found a little too much is better than not enough and the amount of break in or setup time seems to be reduced.

The best test is to run Prime 95 Small FFTs which equally loads your 4 cores. The majority of Core i7-920 CPUs I've seen will show a difference of about 5C between core 0 and core 3 with the two center cores somewhere in the middle. If you have something way different than this at full load then it wouldn't hurt to try reinstalling but if your computer is running fine then I wouldn't worry about it.

[PVTCaboose1337]

I'm running my cores a few C apart! Seems to be ok here, also, depends on what programs are running, IE if I am running TF2, major stress on Core 1, vs Core 0.

[unclewebb]

PVTCaboose1337: 45nm Intel Core 2 Duo sensors are completely different than Core i7 sensors. The Core i7 sensors are very consistent from one CPU to the next while Core 2 Duo sensors can be all over the place.

I could use some laptop testers for RealTemp 3.35 that I'm working on. It should be able to show Super Low Frequency Mode (SLFM) correctly where a mobile chip can drop down and use the 3.0X multiplier and when running a single thread of Super PI, you should see it correctly report Intel Dynamic Acceleration mode.

http://www.fileden.com/files/2008/3/...alTempBeta.zip

Post some screen shots so we can both learn more about your P8700.

[Depth]

Originally Posted by JOhn Magee

I'm using the i7 920 and RealTemp shows 35-28-34-27. Is this big a difference normal or do you think I may have done poorly applying the thermal paste (I hear that a thin layer is better than thick)
Thanks

Sounds like you got an uneven spread. It won't matter and it will run perfectly fine, but if you're picky and got the tools needed to clean the old paste off then you could try reapplying it.

In a perfect world you'd want the paste to be a molecule thick but use too little and you get an uneven cover, giving an uneven heat buildup. Use too much and it wont conduct heat as efficiently, giving higher temperatures.

Hope it helps

[JOhn Magee]

Thanks everyone.
Since I get 40 - 34 - 39 - 33, all at idle, and 71-66-67-63 running "small FFT's", I think I can assume that my paste may be uneven. I think I'll try a thinner layer and maybe tighten the screws on the Scythe Mugen-2 and see what that does - when I have nothing better to do.

[Binge]

Originally Posted by JOhn Magee

Thanks everyone.
Since I get 40 - 34 - 39 - 33, all at idle, I think I can assume that my paste may be uneven. I think I'll try a thinner layer and maybe tighten the screws on the Scythe Mugen-2 and see what that does - when I have nothing better to do.

It probably means that the mugen doesn't have enough surface area contact at the center of the chip. Try reseating and reapplying thermal paste. Usually core temps are within 1-2C difference like this... 33-32-33-31

[aximbigfan]

I have an i7 920. My idle temps are
0: 41
1: 40
2: 40
3: 38

[Speedi]

Originally Posted by JOhn Magee

Thanks everyone.
Since I get 40 - 34 - 39 - 33, all at idle, and 71-66-67-63 running "small FFT's", I think I can assume that my paste may be uneven. I think I'll try a thinner layer and maybe tighten the screws on the Scythe Mugen-2 and see what that does - when I have nothing better to do.

Interesting. I am getting 38-32-40-33 on my Core i7-920. I am using Real Temp 3.00 to measure the temps. The thing though, I read, was that Real Temp 3.00 needed to be calibrated. This means that the temps should be 5-6C above ambient room temp, according to the documentation, and that you need to 'calibrate' it based on those values.

The cooler I am using is the H50 from Corsair, so thermal paste was already applied - it looked good and looked to be very even. Since I'm sure Corsair would want their device to perform, I wouldn't think they would apply cheap thermal paste to it.

I have some cleaner and some AS5, so I could replace it... but I don't want to if there is the possibility that the sensors need to be calibrated.

Any thoughts on that?

[KieranD]

a few suggestions
the cooler isnt flat and needs lapped or the cpu needs lapped
the load on the cores is different
the monitor/sensor is broke or out of wack

[unclewebb]

Speedi, it's best to run Prime 95 Small FFTs and get your CPU temperature higher. These sensors tend to be more accurate at higher temperatures than what they are at lower idle temperatures. I recommend P95 and this specific test because of the consistent load it applies to each core. Perfect for comparing sensors.

If the core temperatures get high enough, you will typically see a pattern develop that often times has very little to do with the flatness of your cooler or how you applied your paste. Most of the difference that people see is sensor error and likely how TJMax is set by Intel. The RealTemp Cool Down Test is also a good source of information because it runs your CPU at several fixed loads so you can better compare. A similar difference at several different load points is almost always a sign of differences in TJMax from core to core. When testing, let the test run by itself and don't surf the net or do a virus scan while the test is running.

Here's RealTemp 3.36. Lots of minor improvements.

http://www.fileden.com/files/2008/3/...alTempBeta.zip

The i7-920 sensors are completely different than the original 65nm or Core 2 45nm sensors. They are very consistent from one CPU to the next. The Core 2 45nm sensors were horrible.

[somebody]

Multi seems fine on 3.36 but if the BUS speed is changed the BUS speed doesn't appear to update until under load. The VID info seems a little high, +112.5mV on the P8400.

[unclewebb]

I'll have a look at the VID info for the mobile processors when I get the chance. My original formula was for the Core 2 desktop CPUs and RealTemp reports the same as CPU-Z or Core Temp for all of the CPUs I've seen compared. Could you post a screen shot comparing those 3 programs? It's possible I might have to update my formula to better support the mobile CPUs.

You're right about the incorrect bus speed on mobile chips at idle. Here's why.

When a CPU is idle, to correctly calculate the MHz, you have to make sure a core is awake and you have to fully load it for a short period of time so you can accurately measure the MHz. If you want to see what I mean, run Process Explorer and compare RealTemp to CPU-Z. CPU-Z uses a lot of CPU cycles to accurately calculate the FSB speed by constantly loading the CPU in short bursts. You will likely see the constant spike in CPU activity as it is doing this.

There's my dilemma. I know how to make the FSB MHz more accurate at idle but on a laptop, I'm not sure if I want to. If it means decreased battery life for users then in my opinion, it's really not worth it. I could always add an option to RealTemp for users that want me to load their CPU for more accurate FSB MHz at idle.

RealTemp might show the FSB speed dropping at idle. If your normal bus speed is 333 MHz and your core is asleep half the time then RealTemp will report something like 166 MHz at idle which is more of a measure of your effective CPU FSB speed. Most desktop chips don't have this issue at idle.

The mobile CPUs were not top priority when I first wrote RealTemp but now I have some extra time and I will be looking into this further. I'll try to send you a testing program I sent to burebista that shows the effective FSB MHz on both of your cores at the same time. It's kind of interesting compared to CPU-Z on mobile chips.

[somebody]

Here you go.

[burebista]

Originally Posted by unclewebb

I'll try to send you a testing program I sent to burebista that shows the effective FSB MHz on both of your cores at the same time. It's kind of interesting compared to CPU-Z on mobile chips.

Yeah, my E8400 is kinda funny in idle.



You, you, you...Canadian guy. You have some movies waiting...

[unclewebb]

somebody: Can you try that test and compare the 3 programs at full load as well? If they are different at full load too then I'll have to have a closer look at the datasheets. I think I have enough data from your previous tests available. Have you ever tested the actual voltage your CPU is getting with a multimeter at idle and at full load? I know you were playing around with that before so it would be interesting to see how actual voltage compares to the VID numbers.

burebista's E8400 has been a thorn in my side for years.

We both have the same CPU, same stepping but different motherboards and the other difference is we live on opposite sides of the world. When using my FSB MHz testing program, at idle or full load it reports a rock steady 500.000 MHz. On his motherboard, this same program shows the effective MHz dropping like a rock similar to what your mobile CPU would show. I've programmed RealTemp to mostly ignore this at idle. Once I get this little testing tool updated so it correctly determines the default multiplier in your laptop, I will post it here so you can check out what your laptop has to say. My wife's T7200 also shows a steady MHz at idle so I'm wondering what power saving features are built into motherboards where burebista lives.

With both cores reporting the exact same MHz, I think this tool is capable of showing something that CPU-Z is not but I'm not quite sure what that something is yet.

Here's my E8400 at idle. It rarely budges at idle or full load.

[pantherx12]

Mine is 25-34-34-25 at the moment, idle.

How's that for a difference? under load there's a 20 c difference!

[unclewebb]

somebody: I just checked the Intel docs and for the P8400 they have 3 slightly different models listed and all of them list the VID as 1.00 to 1.250 volts. Here's an example:

http://processorfinder.intel.com/det...px?sSpec=SLB3Q

Edit: I think I found the problem. I'll have a good look at the datasheets tomorrow and see if I can get VID fixed up for the 45nm mobile chips. Thanks for bringing it to my attention.

[somebody]

Same difference at 9.0x. Of course all my real voltages are higher than the requested VID as I have hardware modded the VR (Voltage Regulator).

Before the mod I measured core voltages with an uncalibrated meter and they were less than VID by up to a maximum of 9mV. Had to put a load on each of the fixed multi's to do that as when idle I would get some readings below what I thought was the minimum (0.925V) of ~0.8V. C-states maybe?

For my P8400

• max at HFM is 1.1375V (VID 0x22), min at LFM 1.0V (VID 0x17).
• max at IDA is 1.2V (VID 0x27), min at SLFM is 0.925V (VID 0x11).

[unclewebb]

Thanks for the info. With those numbers and the datasheets, it should be easy enough to mod my VID formula so the 45nm Core 2 mobile chips are reported correctly.

Edit: Can you try RealTemp 3.37?

http://www.sendspace.com/file/nsqj8n

Hopefully this will report VID correctly when using a 45nm mobile CPU.

burebista sent me a movie or two and showed me how the drooping FSB MHz happens when C-states is enabled in his bios. You can try playing around with that while I decide or figure out what to do about this issue on the mobile chips.

[somebody]

3.37 VID works perfectly with the P8400.

I never got the FSB program to try out or don't know where to download it.

[unclewebb]

3.37 VID works perfectly with the P8400

One less thing to worry about.
I totally overlooked this. I've been mostly concentrating on the Desktop CPUs but I'm glad that I've got this issue and the SLFM issue and IDA issue fixed now. One more issue to go. The FSB MHz issue.

http://www.fileden.com/files/2008/3/...07/MHzTest.zip

I needed to do an update to my MHz testing program to properly support your IDA capable CPU.

I'm very interested to see what it shows.

The new Core i7 and i5 CPUs have what's called an invariant TSC or time stamp counter. What that means is the the internal counter will count at a continuous pace, regardless if a core goes into a C state or sleep state. This makes calculating MHz fool proof without having to load the CPU in a busy loop.

I think the Core 2 CPUs don't have this feature. When they enter a deep sleep state, the internal TSC counter stops counting.

To calculate MHz it is a very simple task. You do a RDTSC or read time stamp counter, wait a second, read the time stamp counter again and then it's pretty simple math to calculate how many cycles per second a CPU is running at. If a core or cores go to sleep, then you can see this method falls apart and will return a lower MHz number than your actual bus speed. If your FSB is at 333.3 MHz and it shows 166.6 MHz then that's a sign that the core or cores must have been asleep half the time.

As I said before, one way around this is to put the CPU into a busy loop to prevent it from going into a sleep state then you are guaranteed to get an accurate count when you do a rdtsc to read the counter. Obviously you wouldn't want to do this very often or for very long. No one wants a monitoring program to be unnecessarily loading their CPU, especially laptop owners. In my opinion, CPU-Z is doing too much of this loading.

Once I see your results somebody then I'll tell you a couple of possible solutions to get RealTemp looking better. I'm also going to modify my program tomorrow to see how long you need to load a CPU to get an accurate MHz number. Does SetFSB or similar program work on your computer or is the FSB speed fixed?

The interesting thing I found about burebista's testing is that this testing program does the same MHz calculation twice, once for each core. Even when the MHz is sagging at idle, both cores tend to report the same MHz are very close to it which to me is a sign that both cores must be going to sleep the same amount of time. I'm not sure what your mobile CPU will show.

Edit: I just read the CPUID docs some more and found another way to calculate MHz that might get around this problem that is compatible with Core 2 CPUs. I'll test that tomorrow.

[somebody]

Originally Posted by unclewebb

I think the Core 2 CPUs don't have this feature. When they enter a deep sleep state, the internal TSC counter stops counting.

From what I've seen that sounds right.

Originally Posted by unclewebb

Does SetFSB or similar program work on your computer or is the FSB speed fixed?

My laptop uses some Silego cost reduced ck505 wannabe that doesn't support a programmable divider. The best I can do is a spread spectrum shift of ~1MHz

Originally Posted by unclewebb

The interesting thing I found about burebista's testing is that this testing program does the same MHz calculation twice, once for each core. Even when the MHz is sagging at idle, both cores tend to report the same MHz are very close to it which to me is a sign that both cores must be going to sleep the same amount of time.

Yep, both readings are pretty close even the same quite often. Without a load it can read down to as low as ~21.