Real Temp - New temp program for Intel Core processors

I haven't updated the GT version of RealTemp since the original came out last October. Maybe when I get around to fixing that, I will add an option so it will continue to call your 6 core CPU a Core i9.

Intel's numbering scheme sometimes makes no sense. They have a Core i7-620M which is a 32nm dual core mobile CPU with integrated graphics, they have the 45nm Core i7-920 Quad core processor and then they decide to call the 6 core version a Core i7-980X. They can't all be Core i7 but they are.

Car companies like to do the same thing where they will bastardize a model name over the years because it was popular with consumers. In the tech world, things move at a faster pace so when Intel comes up with a model number that is popular like the original Core i7-920 was, they bastardize that name and stick it on pretty much anything if it might lead to more CPU sales. :D

The E6300 is another good example. This was the first Core 2 Duo and became an instant overclocking legend with overclocks approaching 100% on a good board. The original E6300 had 2MB of L2 cache and ran at 1.86 GHz then they released an E6320 with 4MB of L2 cache and then later on they went back in time and combined the E6300 model number with their other old favorite, the Pentium, and produced an Intel Pentium E6300 that runs at 2.80 GHz and has nothing to do with the original. Programmers have a hard time keeping up with this let alone consumers. :rofl:

are you saying basically that a I7 920 would read it's TJmax strait out of the die or MSR? so RT automatically detect the approximate accurate TJ for any processor it operates upon?

2. going over some portions of this thread and the other at overclock.net, it seems that the delta between the DTS and the Tcase is only 1-1.5 degrees?
so an I7 9xx with a Tcase of 67.9 should not exceed core temperatures of ~66.5?

3. have anyone used HWMonitor? it has few temperatures reading out of the IPEC chip which are showing the CPU is ~15 degrees lower then the core temps,
and so, setting up Smart Fan through the BIOS to operate at 60C< go 100% CPU fan actually makes the fan go 100% only at 75 core degrees, i.e 10-15 above the the HWMonitor CPU reading...

so with these parameters there seems to be a conflict between the DTS core reading and the Tcase or PECI or whatever is reading the CPU at 15 degrees less,
what makes one believe the actual Tj for the 9xx is actually 85C and not 100c.

any idea..?

Quote:

---

Originally Posted by unclewebb

TM Load stands for Task Manager load meter. That option uses a Windows function similar to what the Task Manager uses to calculate CPU load. The best method for Core i CPUs is to un-check this box and use the original method based on CPU C0%. TM Load is designed for Core 2 mobile CPUs that go into low power sleep states at idle.

I have no idea what you did and no idea why it doesn't work anymore. I've never seen this problem before.

Here's the latest version. It has a couple of more minor features like better system tray fonts so you might as well try it even though I doubt it will fix your problem.

RealTemp 3.59.5
http://www.mediafire.com/?vc6w5frn1gclpu9

---

Wow...,thanks Uncle,
RealTemp 3.59.5,it's 2 weeks to post here.

The value stored in each core is called the TJ Target value. According to Intel, that is the minimum value that throttling will begin so I would disagree on a TJMax=85C theory.

I think the actual TJMax on core 0 of the Core i7-920 CPUs is extremely close to 100C and the reported core temperature coming from that core is more accurate than any CPU Intel has produced. Intel took a lot of flak for the crappy 45nm sensors they used on their Core 2 CPUs so decided to spend a few more pennies on the Core i7-900 series and it shows. The newer 32nm sensors are a step backwards.

I disagree with some of the stuff on overclock.net and haven't been there for a while to read any new theories. When you are running a stress testing program like Intel Linpack, the difference between peak core temperature at the hottest spot on the core and case temperature can hit over 25C. It's definitely a lot more than 1C or 2C. The Tcase specification is designed for system builders. The theory is that if you select a computer case and choose some fans and if you design a computer so the Tcase temperature doesn't exceed 67.9C during your test, then a system builder will not have to worry about the peak core temperature hitting the thermal throttling point at 100C very often if at all during normal use. That's all Intel cares about. They design their CPUs to run reliably up to a core temperature of 100C so as long as the core temperature never triggers thermal throttling, the user will have a CPU that performs at the speed that Intel designed it to run at.

The CPU temperature reported in the bios and by all software that reports that sensor has nothing to do with actual Tcase temperature. The only way to measure the Tcase temperature according to Intel is to cut a groove in the top of the CPU heat spreader and to run a thermocouple to the geometric center. The 67.9C Tcase specification can only be compared to a temperature measured using this method.

Quote:

---

RealTemp 3.59.5,it's 2 weeks to post here.

---

I must have forgot about that one. :)
I kind of like the new system tray font options but other than that it's mostly the same old stuff.

Quote:

---

I disagree with some of the stuff on overclock.net and haven't been there for a while to read any new theories. When you are running a stress testing program like Intel Linpack, the difference between peak core temperature at the hottest spot on the core and case temperature can hit over 25C. It's definitely a lot more than 1C or 2C.

---

yeah, had this idea too,
it's quite impossible that the actual core temperature is only a degree lower than the upper side of the IHS,
it's like sticking your hand into the fire, or placing it half a meter above,
have a look here:
http://www.semiaccurate.com/static/u...hermal_pic.jpg
http://www.semiaccurate.com/2010/07/...are-defective/
if different adjacent parts of the die can differ by 10 degrees or more, there's no reason the top IHS side, with half a mm thick metal between it would not be delta'ed even up to 15 degrees.

testing a naked chip with an IR thermometer at low voltage and power consumption may reduce heat delta between the IHS and the cores to what has been read as 1.5 degrees, while when the chip is hot running under fan easily reaching 80 degrees, the delta could be much higher,
it's possible that MB manufacturers take this into account and placing they're reading already 15 degrees lower than the cores, or taking a Tcase reading as this is what they face setting up cooling solutions for, it's still kind of strange though,

Quote:

---

The Tcase specification is designed for system builders. The theory is that if you select a computer case and choose some fans and if you design a computer so the Tcase temperature doesn't exceed 67.9C during your test, then a system builder will not have to worry about the peak core temperature hitting the thermal throttling point at 100C very often if at all during normal use.

---

what means, is the CPU can take at least Tcase+delta to Tjunction, i.e - 67.9 + ~15 = ~83C.
E: seems you've been discussing this issue inside out and agreed the max delta between TJmax and IHS temperature is to be ~5 degrees at temperature close to TJmax,

a clarify: the 85 degrees is not a theory actually, more of a confusion with Smart Fan and Tcontrol.


yes CPU's can reach 100 degrees before throttling, so it can be taken as still under safty standards temperature, yet it doesn't mean they can take these degrees 24/7 for a long period without getting decayed faster then at ~70 or so.

Quote:

---

They design their CPUs to run reliably up to a core temperature of 100C so as long as the core temperature never triggers thermal throttling, the user will have a CPU that performs at the speed that Intel designed it to run at.

---

that's interesting, so the delta taken from Tjmax to Tcase is ~25 degrees for the I7 or so with few degrees as a safety headroom,
that actually clarifies many things, the actual MB reading for Smart Fan is not that critical, it definitely isn't more accurate or crucial than the DTS reading,
only secondary,

thanks for your input :up:.

E:
after going over page 86 and it's area, your statement of 25 degrees delta between core temp and Tcase is quite confusing,
rge has seemed to propose that the max difference between the two is somewhere in between 5-7 degrees, which seems very logical considering the short physical distance between the two,
as to add to that, these^^ sort of pictures above doesn't add any to clear up the confusion :/.

E2: according to Toms article on Core 2 DTS specs the deviation in temperature reading by the DTS can range in between -5 to +10 at 90 degrees.
which means, if the IR reading at 90 degrees go for 85 at the IHS, the actual core temperature can be actually between 85-100, i.e up to 15 degrees over Tcase temperature.

whether it was posted here or not, I7 TJmax can be read from the MSR at address 1A2h bits 16-23,
the value stands for 64h (100).

Quote:

---

Originally Posted by unclewebb

I must have forgot about that one. :)
I kind of like the new system tray font options but other than that it's mostly the same old stuff.

---

:up:
Accepted.
Keep your well work!

Quote:

---

yes CPU's can reach 100 degrees before throttling, so it can be taken as still under safty standards temperature, yet it doesn't mean they can take these degrees 24/7 for a long period without getting decayed faster then at ~70 or so.

---

I haven't seen any test showing how long you can reliably run an Intel CPU at a core temperature of 100C for. If not overclocked, I think it's possible to run it 24/7 for a long, long time without any problems but the longest test I've ever done was running Prime95 for 3 hours with the CPU heatsink fan disconnected. My E8400 bounced continuously off the thermal throttle but other than that, it ran fine without any errors while over clocked 20% and over volted.

If you used a little more common sense than that, an Intel CPU would probably run reliably for a long time, even at a peak core temperature of 100C.

I know some people that don't look inside their computer, ever, can end up with the heatsinks full of dust and dirt and even the CPU fans can fail and users barely notice. They might throttle and run a little slow but whatever, they just keep using them. The Intel thermal shutdown temperature isn't until 125C so I think Intel CPUs have a significant amount of temperature headroom in their design and can run a long time reliably, even when running red hot.

The 5C to 7C difference between peak core temperature and Tcase temperature that rge discovered was when the CPU was idle. That can increase significantly depending on what type of software you are running. Different loads work different parts of the core harder as your thermal picture shows. Intel also makes a lot of different CPUs and the delta at full load running Prime95 or LinX/Linpack is going to vary depending on whether you are testing a 65nm dual core or a 45nm Core 2 Quad Core or a Core i7-920 that is laid out completely different. The distance from the hottest spot on the core to the temperature at the center of the CPU on top of the heatspreader is going to vary.

MSR register 0x1A2 only applies to the newer Core i based CPUs but there is no guarantee that number is the same as actual TJMax. Intel officially calls this "temperature target" and admits that actual TJMax can and does vary. They've just never clarified by how much this might vary or whether it varies from core to core like I think it does. A number with no error specification is wide open to interpretation.

They've never released any engineering type data showing the details about their calibration procedure or how much error is in that procedure or the sensors they use. The numbers released at the IDF Conference and quoted in the Tom's article are more like approximations. Intel builds a lot of different CPU types with different sensors so people shouldn't read too much into a blanket statement like that without them producing engineering test data for the different models. The Core i7-920 sensors are completely different sensors than what the 45nm Core 2 CPUs were saddled with so a statement that applies to one may not apply to the other.

onex, the gradient from core to IHS depends on the total dissipated power, ie TDP. At idle and very low volts, TDP is only few watts, and there is a gradient of only 5-6C from core to IHS, which is the minimum gradient you will see. At undervolted, underclocked load, may only have 10-12C core to IHS gradient. However, at stock settings, for example my E8400 was 23C+ gradient from core to IHS at linpack load, measured using two calibrated thermocouples, one embedded in IHS, and one embedded in die, via hole drilled through IHS and partway into die, pics in link below.

First link shows video of 23C gradient of my E8400 at stock settings loaded with linpack.
http://www.youtube.com/watch?v=q7ua2FFByfI

original post here: http://www.xtremesystems.org/forums/...postcount=2418

And her is pic of hole drilled in my cpu and into die (E8400), along with stanford paper that also measured gradient from IHS to die, also found 20-30C gradient with some loading programs.
http://www.xtremesystems.org/forums/...postcount=2438

You can also look at intel published specs, for example IHS max temp of my old E8400 was 72.4C per intel, and tjmax was 100C. These numbers are actually the same limit, ie when tjmax limit is reached at full load 100C, intel says can also measure IHS at 72C, depending on intel testing conditions, intel loading program, at stock settings, stock cooler, ie can be 28C gradient from core to IHS (typically worst case scenario).

Once you start overclocking and increasing TDP, this gradient can increase, though changing cooling changes gradient as well.

Quote:

---

Intel officially calls this "temperature target" and admits that actual TJMax can and does vary. They've just never clarified by how much this might vary or whether it varies from core to core like I think it does.

---

yes, that's exactly the issue which causes all that confusion,
there isn't seem to one answer to these questions but rather explanations which are going round and round not hitting the main issue.
the DTS's are said to be upgraded at each processor release and so does they're calibration,
taking approximations made for Core 2 might not be as accurate for the Core I,
the basic issue is that indeed, there doesn't seem to be any documents that actually eliminate this problem and neither Intel seems to know the exact answer which make it rely basically on assumptions and safety offset calibrations as well.

Quote:

---

If you used a little more common sense than that, an Intel CPU would probably run reliably for a long time, even at a peak core temperature of 100C.

---

people are saying that high temperature has a wider effect on electromigration,
though Intel wouldn't have released PROCHOT# at 100C if it was a severe danger to they're processors,
ofcourse Silicon doesn't melt at 100C and some people do run they're processors at above 90 degrees for folding, yet still it seems high temperature has an effect on microprocessors,
Intel may allow processors to reach 100C or in fact, even 105-125 at THERMTRIP# yet doesn't advise it for long periods,
few degrees below Tcase temperature is used to activate Smart Fan through the PECI interface, at 60 degrees.

http://en.wikipedia.org/wiki/Electro...n-aware_design

Quote:

---

Electromigration reliability of a wire (Black's equation)

At the end of the 1960s J. R. Black developed an empirical model to estimate the MTTF (mean time to failure) of a wire, taking electromigration into consideration:

\text{MTTF} = A (J^{-n}) e^{\frac{E_a}{k T}}

Here A is a constant based on the cross-sectional area of the interconnect, J is the current density, Ea is the activation energy (e.g. 0.7 eV for grain boundary diffusion in aluminum), k is the Boltzmann's constant, T is the temperature and n a scaling factor (usually set to 2 according to Black). It is clear that current density J and (less so) the temperature T are deciding factors in the design process that affect electromigration.

The temperature of the conductor appears in the exponent, i.e. it strongly affects the MTTF of the interconnect. For an interconnect to remain reliable in rising temperatures, the maximum tolerable current density of the conductor must necessarily decrease.

---

http://doc.utwente.nl/47484/1/01315418.pdf

Quote:

---

We present a significant reduction in EM-lifetime when a
temperature gradient is present within a metal line, even when the
line has a lower average temperature. TM, the diffusion of atoms due
to a temperature gradient, cannot explain this. Ihe temperature
gradient enhances the electromigration process. The failures will
occur mainly near the local heating elements at the site of maximum
temperature gradient.

---

i'm not an expert and neither an engineer, but i use logic before posting and after and do take things into account.
not saying that a processor would end it's life after 2 years while running at 95C yet indeed it can take away some of it's capabilities and shorten it's life.
that's why the companies regulate temperatures and advise keeping them well below the periodical-safe maximum.

brilliant rge,
will take a deep look over this post later.

E:
so that video says it all, and that CPU is a 65W one.

the university testing also approve these testing by a brief going over the document and the image,
seems the gradient indeed reaches up to 20+ degrees at some applications.

Quote:

---

You can also look at intel published specs, for example IHS max temp of my old E8400 was 72.4C per intel, and tjmax was 100C.

---

and that clears out further the confusion as Intel reading for Tcase vs DTS temperature means while using a HS.
this pretty much sums it up,
great endeavor!

p.s - that document is really interesting!

Quote:

---

the DTS's are said to be upgraded at each processor release and so does they're calibration,

---

That's not true. The Core 2 45nm sensors weren't as accurate as the previous Core 2 65nm CPUs. After all the problems with the 45nm Core 2 sensors, Intel used some of their best sensors ever on the original Core i7-900 series. The 32nm sensors they have switched to for the Core i7-980X don't seem to be as accurate.

yes, that's correct,
seen somewhere about the 980 not being too accurate,
as for the improvement by each generation,
Intel is saying that through one of it's thermal papers (should be the last I7 one or CPU Monitoring
With DTS/PECI), the I7 sensors should be indeed very well implemented, thought that's coming out of scattered pieces of information from many different places.

the main issue got cleared and that's really what matters, maybe and probably for you as a software builder for these purposes, that should be more of a concern,

as a side note,
the 980 is a die shrink processor, a sub process in between two major one's, the SB should probably offer well implemented sensors as a new architecture same as the I7 did or maybe even better,
the attention for better sensor seems to have started with the I7's.

Intel would probably spend more effort in they're design with SB rather than with an intermediate process such as the westmere (or Gulftown for that matter).
it looks like it is looking forward and is becoming more and more aware at these issues, at least by the papers, it doesn't seem like it would step back any more rather if the implementation of DTS's and they're accuracy is getting harder to sustain with every die shrinking process.

hoh, and thank u for all you'r great work, both in this area and with the Intel Dynamic Acceleration at Throttle stop,
you guys are doing a great job.

unclewebb
What about some improvement of design?

Quote:

---

Originally Posted by WaterFlex

What about some improvement of design?

---

After a million downloads during the last year, the user community has shown me that they like RealTemp but hardly anyone is willing to contribute by donating some money to this project. I have donated thousands of hours of my time but 99.999% of users have donated nothing. Here's what 6 months of donations look like and most of those donations are for my new program, ThrottleStop.

http://img840.imageshack.us/img840/3...tincome.th.png

I wasn't expecting this to be a get rich quick scheme but when I can't afford any new hardware or software to develop on, I have to look at doing other things with my time. RealTemp is free to use but it hasn't been free to develop.

The good news is that I finally updated RealTemp GT for the Gulftown 6 core users and got the ATI and Nvidia GPU stuff working last night. That should be ready for testing in a day or two. When I can afford to buy some Sandy Bridge hardware, maybe I'll do a maintenance release next year if it is needed.

how does one donate unclewebb?

unclewebb, you're much appreciated. Thanks for the time & effort.

Quote:

---

Originally Posted by unclewebb

After a million downloads during the last year, the user community has shown me that they like RealTemp but hardly anyone is willing to contribute by donating some money to this project. I have donated thousands of hours of my time but 99.999% of users have donated nothing. Here's what 6 months of donations look like and most of those donations are for my new program, ThrottleStop.

<snip image>

I wasn't expecting this to be a get rich quick scheme but when I can't afford any new hardware or software to develop on, I have to look at doing other things with my time. RealTemp is free to use but it hasn't been free to develop.

The good news is that I finally updated RealTemp GT for the Gulftown 6 core users and got the ATI and Nvidia GPU stuff working last night. That should be ready for testing in a day or two. When I can afford to buy some Sandy Bridge hardware, maybe I'll do a maintenance release next year if it is needed.

---

That sucks. The community has really dropped the ball on this one. Donation sent!

Quote:

---

Originally Posted by radaja

how does one donate unclewebb?

---

via paypal to email address: monitrex@yahoo.ca
previously posted in this thread over 1 1/2 years ago.

Previous PayPal post by unclewebb

EDIT: unclewebb, you should add your paypal info to the first post. I had to search for it, which unfortunately gives people an easy reason to opt out.

Quote:

---

Originally Posted by sn0man

unclewebb, you're much appreciated. Thanks for the time & effort.

---

Talk is cheap, how about a donation? :up:

sdsdv10,thanks for the link

How about integration of shell for G15 display like CT has in future? I apologize if it's awkward moment to ask for
due to donation issue.

RealTemp 3.59.6 + RealTemp GT 3.59.0
http://www.fileden.com/files/2008/3/...alTempBeta.zip
http://www.mediafire.com/?2a7pn2f1y2kql01

After almost a year, I finally got around to updating RealTemp GT. It won't be calling everything and anything a Core i9 anymore.
I don't have any 6 core CPUs to test with so if anything needs fixing, let me know.

Erklat: Core Temp's G15 support works so I probably won't bother with this feature.

First thanks for the link sdsdv10 :D

Donation sent!

Second and foremost. Thank you so much for an awesome program unclewebb. Love the new additions to Real Temp GT. It looks awesome.

screen shot
http://littlekitty.smugmug.com/Other...4_dxY2R-X3.jpg

Donation sent as a gift. It was not much, mabye I can send more later. Many thanks for all the time and effort you have put into this.

Thanks for posting that picture CKY2K. I'll get the Intel Intel naming bug fixed up in the next release. At least RealTemp GT is finally calling these CPUs Core i7-980X.

I appreciate the donations but I wasn't trying to fleece some more cash out of XS members. People on XS have always been great with donations and especially with feedback. The feedback is the most important part. Without enough hardware to test on, I have to do a lot of guessing so good feedback and showing me when there's a problem is more important than cash.

You only need to use the 3 Digits option for the system tray when you are using Fahrenheit and a tiny font. When monitoring in Celsius, I hope you're not seeing core temperatures over 100C or else there's a problem. The new Core i processors aren't capable of reporting a core temperature beyond 100C so this option isn't needed for most users.

I've been promising the W1zzard over at TechPowerUp a new version for quite a while now. It looks like it's almost ready for prime time.

The last thing I'll be adding to RT is adjustable turbo multipliers. That's a handy feature for the Core i Extreme and K series CPUs. I'll send the new version to you CKY2K within a couple of days for some testing.

No problem unclewebb and thank you. Does the 3 Digits option also work in Celsius? "The new Core i processors aren't capable of reporting a core temperature beyond 100C so this option isn't needed for most users" I've been there a few times with an ES & Retail-980x. The highest I've seen with Real Temp on one core was 104C with an ES (screen shot if you want), retail was 101C.

I always try to post new versions of Real Temp over at evga. I hope it helps :D.
http://www.evga.com/forums/tm.aspx?m=581948

My mistake. I was thinking about the original Core i7-920 retail CPUs that had a maximum core temperature of 100C but you're right, some of the newer Core i CPUs go to 101C like your Core i7-980X and I think some of the mobile Core i CPUs top out at 105C.

After this point, even if the CPU gets hotter, the sensor will keep outputting the same data and won't go any higher than whatever TJMax is for the CPU. I used to be able to trick the Core 2 based CPUs and still get some data out of them but Intel blocked this little trick in the Core i design. Coincidence I'm sure. :)

With a normal sized font and the Three Digit option, you won't be able to see all three digits very well because there is a very limited amount of space in the system tray. For testing, switch to Fahrenheit and you'll see what I mean. The only way to see three digits is to use a tiny font. I use Celsius so I prefer not using the 3 digit option. When the temperature gets up to say 101C, by default, RealTemp will drop the first one and show that temperature as 01 in the system tray. If you are overclocking and running your computer on the ragged edge, I think you will know that 01 means 101C and not 1C. 1C or 5C will show up as the single digit 1 or 5 without the zero in front of it.

Thanks for sharing RealTemp with others that don't hang out at XS.

donation sent:D
for all the hard work you put into this great
program,it is a pleasure to help out any way
i can.thank you very much for realtemp:up:

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

- added a feature to allow access to the turbo multipliers and turbo TDP/TDC settings in the Extreme and K series CPUs.
- fixed the minor Intel Intel naming bug.

Can someone with an Extreme or K series CPU right click on the RealTemp GT icon in the system tray and test out the new Turbo Boost Limits option. Intel plans on adding more K series CPUs for enthusiasts to their new line up so I thought giving users some control over the turbo multipliers and turbo TDP/TDC settings would be a good thing to add to RealTemp. On a regular Core i CPU, this new feature should show you the default values for your CPU but the adjusters will be locked. The adjusters will only be unlocked if your CPU supports this feature.

Increasing the turbo TDP/TDC limits on a Core i7 Extreme mobile CPU like the 920XM or 940XM can double the amount of energy going through your CPU which will significantly increase your full load core temperatures so try to use some common sense. That might be hard when your jaw hits the floor. :D

These new features have only been added to the RealTemp GT version at the moment but as soon as I get some feedback and see some screen shots, I'll be adding this feature back to the regular version of RealTemp as well.

Let me know if there are any problems.

Thanks radaja for your support.

http://img801.imageshack.us/img801/3079/rtgt.png

I know my cpu is not supported but just posting to show it works and it is locked on 920's.

I absolutely love it! Thank you for your continued efforts on this app. Me and my i7 980x thank you!

http://img202.imageshack.us/f/rtgt133x24x3002.png/

Well, there used to be an image here.

Go here: http://img202.imageshack.us/f/rtgt133x24x3002.png/

Go here:

http://img138.imageshack.us/img138/8...33x24x3004.png

There is clearly some kind of posting rule I do not understand.

acebmxer: Thanks for that post. Most of the new code was a Copy & Paste from my ThrottleStop program but it's always nice to see that I didn't screw something up.

On the Core i Extreme CPUs or on the K series, the adjusters will be unlocked and it will be easy to bump the turbo multipliers up a notch or two.

The Turbo TDP/TDC power limits are a great feature for the Extreme mobile CPUs. I think the 940XM has a default TDP/TDC of 62/62. When you increase that to 90 or 100, you get a lot more turbo boost and a huge increase in performance. No more turbo throttling. I'm sure Intel will be impressed. :D

If you have a desktop board with limited TDP/TDC adjustments in the bios, this might also be a useful feature when overclocking to prevent turbo boost from getting throttled.

ehume: Can you lower or raise your turbo multipliers from the 30 that they are set to?
Thanks for the images. Some boards set TDP/TDC very high to prevent the CPU from doing any turbo throttling at full load.

Quote:

---

Originally Posted by unclewebb

ehume: Can you lower or raise your turbo multipliers from the 30 that they are set to?
Thanks for the images. Some boards set TDP/TDC very high to prevent the CPU from doing any turbo throttling at full load.

---

Please explain what TDP and TDC are. Intel uses a 'TDP', but that is Tcase.

I was just now testing out the Turbo multipliers. According to Real Temp GT, my multipliers slow down nicely when the load is off, but run up beautifully when the load is on. I am now running at a default of 22x134MHz, with HT, TB, C1E, C-states and EIST all enabled, and Vcore on Auto. Watching RTGT, I have seen the multi drop as low as 10.5. With LinX on, all four cores go up to 30x and the cpu speed up to around 4020MHz.

Weirdly, EasyTune6 does not know how to handle the speed, but reports the same voltage as CPU-Z. But CPU-Z reports cpu speed as 3900-4000MHz, with multipliers running 29x to 30x. Clearly, it can't handle the software-managed Turbo Boost adjustment either.

What you have given me is what I wanted from Asus P7P55 boards: the ability to adjust TB, which the 875k supports.

Bravo!

The turbo TDP/TDC settings that RealTemp now lets you access controls when the processor will give you turbo boost.

For an example lets pretend we have a Core i7-940XM that has these both set to 62. If you are trying to run 8 threads of the wPrime benchmark, when the CPU hits 62 watts of power consumption, these CPUs are designed to immediately turn off the turbo boost so the multiplier will drop back to the default which is only 15. This will reduce power consumption and when the CPU gets back under 62 watts, full turbo boost will resume until you are once again over the 62 watt turbo limit. The CPU is being continuously adjusted like this hundreds of times a second which is why RealTemp calculates the average multiplier using the Intel recommended method. A lot of software doesn't use this method and it shows. I refer to this pattern of turbo boost on and turbo boost off as turbo throttling. By default, the i7-940XM will turbo boost up to a maximum multiplier of 25 but RealTemp can let you go higher than that if you want to. When all 8 threads are fully loaded, you might only average a multiplier of about 20 so you end up losing a lot of performance due to turbo throttling.

Turbo TDC is the amount of current (amps) that flow through your CPU before turbo boost is throttled back. If you boost the turbo TDP/TDC up to about 90, the CPU will continue to give you full turbo boost on all 4 cores even when fully loaded. The 940XM can run all 4 cores with this option with the full 25 turbo boost multiplier on each core. It makes a significant difference when benching and has put a big smile on the Alienware M17x owner's faces over on the Notebook Review forums.

The turbo multiplier reported by RealTemp has always been very accurate. If you have any of this turbo throttling going on when fully loaded, it should pick it up right away.

I just got this new feature added into the regular 4 core version of RealTemp. It's still just being beta tested but should work exactly the same as RealTemp GT is working for you.

http://www.mediafire.com/?s7wlkkrm08386fg

On your CPU, you might be able to lower the TDP/TDC values way down if you want to watch what turbo throttling is all about when you are fully loaded.

Edit: I need to add some code so the turbo multipliers and turbo TDP/TDC values are restored after you do a stand by / resume or hibernate / resume cycle. If you ever accidentally save some sky high multipliers and RealTemp keeps trying to use those when you start it and it crashes, just go into the RealTemp.ini file and remove the two keys, ONEADEAX and ONEADEDX. This will prevent RealTemp from using the previously saved values. I might build a little more user friendly safety feature on this so when someone accidentally tries to overclock their CPU to 8000 MHz, it will stop and ask you if you're sure. With XS members, it's never a good idea to assume anything. 200 MHz x 40.0 = hmmm, that seems about right. :)

Edit #2: I fixed up the stand by / resume code and have finalized RealTemp 3.60. Hopefully the W1zzard over at TechPowerUp has a chance to get the download site updated before the weekend.

@unclewebb:

For my setup and screenshots of your software in action, look here.

RealTemp 3.60
http://www.techpowerup.com/downloads...Temp_3.60.html

http://img543.imageshack.us/img543/7049/realtemp360.png

The first official release in a long, long time. Here's the official log:

* Added Core i Turbo multiplier and Turbo TDP/TDC overclocking for Extreme / K series CPUs.
* Added ATI GPU and improved NVIDIA GPU monitoring with CrossFire and SLI support.
* Added a system tray / notification area font selector.
* New Fahrenheit and 3 digit system tray option.
* Fixed Core 2 Extreme multiplier reporting.
* Fixed Core 2 mobile CPU C0% based load reporting.
* Changed how Core 2 Super Low Frequency Mode (SLFM) is reported.
* Improved sensor test consistency.
* Bug with Reset button on ATI systems fixed.
* RealTemp GT for the 6 core Gulftown CPUs was also updated.
* Separate i7 Turbo GT multiplier monitoring tool for 6 core Gulftown CPUs added.
------------------------------------------------------------------------------------------------

ehume: I tested TMonitor a long time ago and all I can say is don't believe what it tells you. It does not follow the Intel recommended method as clearly outlined in their November 2008 Turbo White Paper which rge shared with me a long time ago. RealTemp has been following the correct method ever since then.

rge also did some testing of TMonitor and he wasn't happy either. I try to avoid commenting on the competition but in this case I don't mind to because TMonitor is clearly wrong. So is CPU-Z at idle but a high multiplier makes for a better screen shot at idle so I can understand why CPU-Z does what it does. No one would be happy if they went to do a validation and the true multiplier was displayed.

If you go into the Control Panel -> Power Options and play around with the Minimum processor state setting and set that to a low number like 5%, the RealTemp multiplier will drop down just like TMonitor is showing you. The C1E adjustment in RealTemp can also affect the average multiplier your CPU is operating at when idle.

When RealTemp is showing a dancing multiplier at idle, that's a sign that your CPU is in a state of chaos. The multiplier is constantly jumping up and down because your power saving requests are not in agreement. One wants the CPU to use a high multi and one wants your CPU to use a low multi so it tries to do both. When you fix this problem, the RealTemp multiplier will be very steady. The programmer of Core Temp also decided to start using the Intel recommended method. I have not thoroughly tested the recent version of Core Temp but when I did test it last, it was nice to see that I was finally not the only one trying to do this correctly.

good to see another 'official' release... :up:

http://c.imagehost.org/0269/RT.jpg

went from 3.58.4 to 3.60 and now it doesn't show nvidia temps anymore. have gtx460 sli. driver 258.96.

screenshot is both running simultaneously.

Quote:

---

Originally Posted by werdwerdus

went from 3.58.4 to 3.60 and now it doesn't show nvidia temps anymore. have gtx460 sli. driver 258.96.

screenshot is both running simultaneously.

---

you need to check the 'Nvidia' box in the settings

http://img189.imageshack.us/img189/7049/realtemp360.png

I decided to make the GPU code optional. Not everyone wants RealTemp to monitor both CPU and GPU.
Now it's easy to turn off GPU monitoring if you're benching or something like that.

Quote:

---

Originally Posted by unclewebb

I decided to make the GPU code optional. Not everyone wants RealTemp to monitor both CPU and GPU.
Now it's easy to turn off GPU monitoring if you're benching or something like that.

---

Quote:

---

Originally Posted by Titus

you need to check the 'Nvidia' box in the settings

---

thank you

Quote:

---

Originally Posted by unclewebb

RealTemp 3.60



The first official release in a long, long time. Here's the official log:

* Added Core i Turbo multiplier and Turbo TDP/TDC overclocking for Extreme / K series CPUs.

---

With 980x and Asus R3E BIOS 1102, TDP and TDC are set to 2048 and 4096 when you disable TDP and TDC safety in BIOS.

Quote:

---

Originally Posted by unclewebb

RealTemp 3.60
http://www.techpowerup.com/downloads...Temp_3.60.html
...

---

Thanks unclewebb! :up:

Quote:

---

Originally Posted by Brama

With 980x and Asus R3E BIOS 1102, TDP and TDC are set to 2048 and 4096 when you disable TDP and TDC safety in BIOS.

---

It means you can overclock the :banana::banana::banana::banana: out of your CPU if you have a private nuclear powerplant as a power source. :D

Seriously, those are probably right numbers, as it is meant never to be reached when you disable protection in BIOS.

Those new turbo values in RealTemp control when the CPU is allowed to give you some turbo boost. By setting those two values as high as they can go, that should continue to give you full turbo boost no matter how big a load you are running. I guess Asus learned a thing or two after XS users complained about their P6T series turbo throttling like crazy. No more turbo throttling. :)

Quote:

---

Originally Posted by unclewebb

RealTemp 3.60
ehume: I tested TMonitor a long time ago and all I can say is don't believe what it tells you. It does not follow the Intel recommended method as clearly outlined in their November 2008 Turbo White Paper which rge shared with me a long time ago. RealTemp has been following the correct method ever since then.

rge also did some testing of TMonitor and he wasn't happy either. I try to avoid commenting on the competition but in this case I don't mind to because TMonitor is clearly wrong. So is CPU-Z at idle but a high multiplier makes for a better screen shot at idle so I can understand why CPU-Z does what it does. No one would be happy if they went to do a validation and the true multiplier was displayed.

---

hum hum, you don't know how TMonitor works, do you ?
So how can you tell that it is wrong :shrug:
As a manner of fact, TMonitor is closer to real clocks than CPU-Z is.

Besides, you can understand why CPU-Z does what it does ... I was a bit worrying about your opinion on that subject, what a relief :D

Anyway ... :down:

I'm sorry for disagreeing with TMonitor but when you follow the Intel recommended method, neither CPU-Z or TMonitor shows a multiplier that agrees with that method.

Intel® Turbo Boost Technology in Intel® Core™ Microarchitecture (Nehalem) Based Processors
http://download.intel.com/design/pro...ots/320354.pdf

Quote:

---

hum hum, you don't know how TMonitor works, do you?

---

You're right, I don't know how it works. All I know is that at times it displays multiplier information that is completely different from the method that Intel recommends, I have to conclude that it is wrong. What else can I conclude? All that does is mislead users so they have no idea what's right and what's wrong.

At least you're willing to admit that CPU-Z is not correct at idle. Everyone trusts that program to be 100% accurate and during some situations, it's not even close to that at idle. Once again, it is misleading and users that don't know how to read through the documentation are left wondering what the truth really is. Do you have any documentation from Intel to support the methods you're using for TMonitor?

Edit: Here's an example of what TMonitor tells me for my T8100.

http://img833.imageshack.us/img833/3240/tmonitor.png

This CPU presently has EIST disabled. When you disable EIST in a Core 2 based CPU, the CPU gets locked at a fixed frequency. The multiplier reported in MSR 0x198 never changes from idle to full load.

Using Intel's recommended method to determine the multiplier, RealTemp and ThrottleStop correctly show that the CPU is locked at the 11.5 multiplier.

TMonitor is telling me that at idle the multiplier is at 6.0 and when I apply a load to the CPU, the multiplier goes up and down. That's wrong. The multiplier does not change when EIST is disabled. It can't. If you want to argue, that's great but you need to argue with Intel. TMonitor is just as inaccurate when run on Core i CPUs. It draws a nice graph but the information it is graphing is fundamentally wrong and inaccurate so it's pointless. TMonitor would be a very useful tool if it followed Intel's methods but there's no point in telling users that their CPU is doing something that it isn't.

I just noticed that comment in the post of Ehume :

"At idle, Tmonitor64 thinks it is going at 9x, Real Temp GT thinks the multi is 18.5x and CPU-Z thinks it is 30x. Note that the voltages in ET6 and CPU-Z are below 1v, more in line with a multi of 9x than anything else"

That is all that matters for me.

Of course I admit that CPU-Z is not accurate anymore at idle on latest Intel generations, that is why TMonitor was developped.

That discussion is closed for me, I want everything but a never ending topic about what is the best method to read clock speed. There are as many methods as there are tools to read them.

Quote:

---

Originally Posted by cpuz

Of course I admit that CPU-Z is not accurate anymore at idle on latest Intel generations, that is why TMonitor was developped.

---

Thank you for admitting to that. I've already had to answer one question on a forum today about why RealTemp and CPU-Z are different. It will be nice now when I can direct them to your explanation.

Quote:

---

There are as many methods as there are tools to read them.

---

I agree that programmers have dreamed up a lot of methods. I prefer to stick with the method that the manufacturer recommends to accurately determine the multiplier. Why would Intel come up with such a complex method if it wasn't going to give you accurate results. That makes no sense at all.

You can argue all you want or walk away from the discussion but either way, you don't have a leg to stand on.

Quote:

---

Originally Posted by cpuz

I just noticed that comment in the post of Ehume :

"At idle, Tmonitor64 thinks it is going at 9x, Real Temp GT thinks the multi is 18.5x and CPU-Z thinks it is 30x. Note that the voltages in ET6 and CPU-Z are below 1v, more in line with a multi of 9x than anything else"

That is all that matters for me.

Of course I admit that CPU-Z is not accurate anymore at idle on latest Intel generations, that is why TMonitor was developped.

That discussion is closed for me, I want everything but a never ending topic about what is the best method to read clock speed. There are as many methods as there are tools to read them.

---

Great, now that your here, can you explain how Tmonitor works, because it clearly isnt for reporting mhz. So what is it for?

CPU is at 4.2ghz, EIST, all speedstep/C states are OFF. So should always read 4.2ghz, reading directly from msr always reads multi correct.

pic 1: Tmonitor at idle, not even close to correct mhz.
pics 2 and 3: Tmonitor not even close to correct mhz, and according to intel all active cores are at same frequency, yet tmonitor is showing 3 different frequencies, and none are correct....

so if you can explain the purpose of tmonitor Im all ears...It is like some bizarre merger of load and mhz the purpose of which is???

Since I've been dragged in, I'll comment.

I followed unclewebb's advice on going into Control Panel > Power Options > High Performance > Change Plan Settings > Change advancec power settings > Processor power management > Minimum processor state > 5% (whew). After that CPU-Z dropped down to 9x on idle, a little steadier than Real Temp, which ranged from 9x to 10.5x I think CPU-Z averages a bit more or delays reporting or something. Both are more-or-less consistent with one another, and both now more-or-less agree with TMonitor64. Dropping the minimum processor state setting to under 5% produces no further changes in cpu multiplier: it bottoms out at 9x. Looking at the fluctuating processor load numbers, I suspect that the minimum could be increased without affecting the minimum multiplier.

One thing I noticed when I was using earlier versions of Real Temp and CPU-Z on my setup with an i7 860: with a fixed Vcore and a fixed cpu multiplier (BCLK 182, EIST disabled), while Real Temp and CPU-Z correctly reported that the multiplier was pegged at 22x and the cpu clock at 4004MHz, TMonitor64 reported a range of speeds and multipliers, from 9x (1638MHz) to 22x (4004MHz), depending on processor load. From that I concluded that TMontior64 reporting was aspirational: it reported what the system wanted to do, as opposed to what it was actually doing. Actually, that phenomenon was one of the things that motivated me to get an i7 875k. I figured it would allow me to have my OC up to 4GHz when needed and otherwise plod along with low speeds and low temps. I could get an Asus board for that, but RT 3.60 allows me to get that with my Gigabyte board.

Rather than arguing, you all should be collaborating, sharing info so that your apps agree with each other. Also: RT and CPU-Z need some nice help pages where the lore of using these apps are handled in exposition and in FAQ's. I shouldn't have to have unclewebb holding my hand in fixing my OS for proper flexible OC'ing, for example.

Quote:

---

Originally Posted by rge

Great, now that your here, can you explain how Tmonitor works, because it clearly isnt for reporting mhz. So what is it for?

CPU is at 4.2ghz, EIST, all speedstep/C states are OFF. So should always read 4.2ghz, reading directly from msr always reads multi correct.

pic 1: Tmonitor at idle, not even close to correct mhz.
pics 2 and 3: Tmonitor not even close to correct mhz, and according to intel all active cores are at same frequency, yet tmonitor is showing 3 different frequencies, and none are correct....

so if you can explain the purpose of tmonitor Im all ears...It is like some bizarre merger of load and mhz the purpose of which is???

---

You're right that deserves explanations, you just needed to ask me for them.

In order to make things clear, you have to consider that they are two kinds of cycles (henceforth two kinds of clocks) : physical cycles, and duty cycles.

Physical cycles are the product of the basis frequency provided by the clock gen, times the current multiplier (on NHM, each core can use a different multiplier). Duty cycles are the part of physical cycles that are actually driven to the core. That part does directly depends on the activity of the core, and in some cases can be used as a throttling mechanism.

Measuring the physical clock speed is simple : you measure the bus frequency, then you read the current multiplier in the MSR that you mentionned, and you get the physical clock speed in real time. Most program do not report it on NHM tho, because the MSR does not report turbo mode multipliers, and the reported frequency would not reveal the turbo mode effect. Nethertheless, if you look at that clock speed, you will notice that this is affected by EIST and C1E, since those mechanisms do reduce the multiplier.

So, if you want to report turbo mode clock speed of NHM, you need to use duty cycles. That generates lot of problems, one being that this clock speed does not follow the relation bus x multiplier anymore, because the bus speed keeps reflecting a physical clock (it is like dividing carots by turpines). One example : dynamic FSB is used by some Core 2 mobile processors as a clock reduction mechanism. Dyn FSB consists in dividing by 2 the part of duty cycles, so if your CPU runs at 8x200 = 1600 MHz "physical", it behaves as if it runs at 800 MHz. In that case, it is complicated to display the bus speed (200) x multiplier read (8x) = 800 MHz (duty clock).

At that point, rge, you will note one important thing : the physical and duty clocks can be very different. In your pic1, the physical clock runs at full speed (23x183) because you disabled all multiplier reduction mechanism, nethertheless your CPU has no activity, and only a small part of clocks are duties. So, that makes sense that the duty clock speed is lower than the physical clock speed, I hope you will agree with that.

Now, how do CPU-Z and TMonitor work, and why do they show different results. Both do compute the duty clock speed. So why are they so different ?
CPU-Z uses the Intel method. That method has a major drawback, it reflects its own computation. In other words, the clock computation makes the duty clock increase to its max. Because that computation is done core by core, each of them can even trigger its turbo mode, and in some cases the clock will be showing the turbo mode clock.
Please note that a post-computation is used to make the computed duty clock speed compliant with the bus and multiplier, otherwise you would see clocks that do not result in any possible multiplier.

TMonitor does compute duty clock speed as well, based on the same Intel method (same regs to say it all), but uses a modified algo that does not change the cores activity. As I explained, the duty clocks speed is directly related to the core activity, and that is why TMonitor does closely map the cores activity. In practice, what you see is the core activities translated into multiplier. Here again, a post computation prevents "impossible" values.

pic2 does not show random values (...), but the clocks for each core :
2196 = 183x12
3294 = 183x18
2563 = 183x14
Note that you can display the multipliers instead of the raw clocks, that makes things much easier to visualize.

The challenge was to prevent the duty clock speed from raising during the measurement, but we finally found a way. As a result, the reported values are much much closer to what is actually happening in each core than CPU-Z.

I hope that this answers to your question.

So what you are saying is Tmonitor reports duty clock speed as opposed to physical clock speed. And duty clock speed is basically activity on cores translated into multi hence mhz. It would be useful to add that explanation to the download site.

So when all cores are at 100% load, the duty clock speed will EQUAL physical clock speed.

If I enable EIST/C states then duty clock speed should still EQUAL physical clock speed, since physical clock will then drop with activity as well as duty clock.

However when I disable EIST/C states, duty clock speed will then NOT EQUAL physical clock speed, since duty clock speed is translating activity into multi, but physical clock speed I locked the multi in place by disabling EIST/C states.

As for the reported values of Tmonitor being closer to what is happening than CPU-Z, that part I would disagree with. Tmonitor is almost nonsensical when turning off EIST/C states, since duty cycle speed is "zeroing" at 12 multi though physical clock speed is not "zeroed" there. I could argue why not report zero activity as 0 mhz ie "0" multi. You could say a 0 multi does not exist, but I could say neither does a 12 multi when EIST/C states are disabled.

thanks for taking the time to explain:up:

Quote:

---

Originally Posted by rge

Tmonitor is almost nonsensical when turning off EIST/C states, since duty cycle speed is "zeroing" at 12 multi though physical clock speed is not "zeroed" there. I could argue why not report zero activity as 0 mhz ie "0" multi. You could say a 0 multi does not exist, but I could say neither does a 12 multi when EIST/C states are disabled.

---

yes this is entirely right !
in the 1st version (not distributed), TMonitor was indeed reporting 0 at idle, because it should be like this. But that was very disturbing.

Wow, where to start. First I guess is to say thank you to Franck for replying and discussing the above. Much appreciated.:up:

Quote:

---

Originally Posted by cpuz

(on NHM, each core can use a different multiplier).

---

Just to clarify, I hope you don't mean at the same time here.

Quote:

---

Originally Posted by cpuz

So, if you want to report turbo mode clock speed of NHM, you need to use duty cycles. That generates lot of problems.

---

I don't understand why it has to be so difficult. There are two performance registers for each thread/core that will give the average ratio over time, say every 0.5 seconds. This should take little cycles to achieve and I would expect it have negligible effect on the result.

Quote:

---

Originally Posted by cpuz

TMonitor does compute duty clock speed as well, based on the same Intel method (same regs to say it all), but uses a modified algo that does not change the cores activity.

---

If the core is idle in one of the higher c-states you will need to wake it to read those registers. Does it not then switch to the package performance state whatever that may be at that time?

Quote:

---

Originally Posted by rge

However when I disable EIST/C states, duty clock speed will then NOT EQUAL physical clock speedith.

---

No. If you disable c-states the duty cycle will be 100% therefore equal the physical clock. If you look at your previous ss you haven't fully disabled c-states. If you had C0% would read 100% all the time.


With the Intel method if the core were active for only 1% of the time but for that 1% it was at 21x multi then that's what would show as the multi but it seems your saying TMonitor will reduce that figure because of the small percentage of time that it's been available. Or maybe I've misunderstood. :shrug:

Hmm. CPU-Z - and, apparently, Real Temp - display the BCLKxMULTI=CPUclock, a resource that is supplied to the CPU. TMonitor64 displays the work the CPU is actually doing with the resource provided. Yes?

Quote:

---

Originally Posted by some_one

No. If you disable c-states the duty cycle will be 100% therefore equal the physical clock. If you look at your previous ss you haven't fully disabled c-states. If you had C0% would read 100% all the time.

---

Thats a good point, I missed that. Well technically if I disabled all C states the cpu wouldnt run, because C0 is the operational state:p:. But I understand your point and makes sense, if all rest states were disabled C0 would be 100% and then duty cycle would equal physical clock...C1 (halt state) cant be disabled on cpus, nor do I think C2 can, I can only disable C1e, C3,6,7 and EIST, I should have said the specific ones I disabled.

Quote:

---

With the Intel method if the core were active for only 1% of the time but for that 1% it was at 21x multi then that's what would show as the multi but it seems your saying TMonitor will reduce that figure because of the small percentage of time that it's been available. Or maybe I've misunderstood.

---

That is the way I now understand it to work though cpuz can chime in, which is why I called it a bizarre cross between load and mhz. It sounds like a tool that was designed to primarily measure turbo as from my limited understanding of turbo, it may apply there, and not sure how well it applies outside turbo, especially with power savings disabled.

C-states are initiated by the OS / Software. If the OS / Software never issues a halt / mwait to the CPU then it will not enter C1. Real DOS worked like that, while the cursor is flashing on the screen not doing much the CPU is still running in C0 100% of the time.

Think of it running in an infinite loop while your not doing anything. You can do the same with Windows but your idle temps will go way up.


I'm not really sure this is the right thread to discuss TMonitor but since it's already been brought up. I planned to post the differences between TMonitor and the Intel method but after some lengthy testing it seems there is a bug in which CPU-Z interacts with TMonitor to produce garbage results. Thus I lost what little enthusiasm I had.


Well I guess we can still look at the idle problem.
The big difference between TMonitor and the Intel method is that with the Intel method an average is calculated only while the CPU is doing work where as TMonitor calculates an average over time even while the CPU is idle. Since TMonitor averages idle cycles it is possible for it to report an average frequency much lower than the lowest frequency mode (LFM) of the CPU. IMHO I would think it better to show this than cover it up with a false LFM / multi since that was the way TMonitor was designed to work.
The RealCore EIST multi's shown in bold on the bottom line is averaged from 0.0 seconds to the first time line. S=SLFM, L=LFM and H=HFM. Turbo/IDA shown in yellow. It appears if TMonitor is run while SLFM is inactive it uses the LFM as a minimum threshold. If SLFM then becomes active it incorrectly shows the LFM frequency.

http://img37.imageshack.us/img37/5769/50011263.gif




TMonitor32 1.03 and CPU-Z 1.55
Here you can see how erratic TMonitor is with CPU-Z running too. C3/C6 enabled, C1E disabled, turbo enabled, no performance states, multi controlled by test software which switches back and forth between turbo and 9x/idle every 0.4 seconds on core 0 thread 0.

http://img217.imageshack.us/img217/7296/39473239.gif




Another bug? :(
Core 0 thread 0 is driven on and off as above but with 1.0 second timing and run as high priority. No CPU-Z this time.

http://img512.imageshack.us/img512/2537/34834875.gif

Thank you for the GT update. Just one tiny thing. I am probably stupid and missing a setting but, I set it to ATI in the settings and its reading the temp right but if I mouse over the tray icon the GPU tool tip say Nvidia. Is there a way to change that? If not no biggy but I'm assuming I'm just missing a setting to change:D

Again thanks for the update.:clap:

Using the Intel recommended method to determine the multiplier works excellent and is the most accurate way to determine what physical multiplier the CPU is running at. By reading the two high performance timers for each thread of each core once per second like Intel recommends, you can accurately determine the multiplier without putting any significant load on the CPU. That was the whole reason that Intel included these timers in their CPUs. For accurate monitoring purposes.

Converting duty cycles into some sort of multiplier value really is like converting apples to oranges. The multiplier value that TMonitor shows when a CPU is lightly loaded has absolutely nothing to do with the physical multiplier the CPU is running at. That was clearly proven by the examples posted. For that reason, I don't recommend TMonitor to anyone. Most users that use TMonitor assume that the data is an accurate indication of the physical multiplier the CPU is using when in fact, it is not.

Quote:

---

a bizarre cross between load and mhz

---

That's a good explanation rge.

Thanks bratboy for noticing that bug. RealTemp GT started life as Nvidia only so I guess I forgot to update the GPU pop up information. If this is your only complaint then I'll update it when I have a chance and send you a special bratboy edition. :)

LOL, your much too kind. I had feared you might have gotten tired of people not appreciating your work and moved to other project so I am just thrilled the new version is reading my GPU at all. A fix at some point, whenever its convienent for you will be just fine. Don't fuss over it just because of me, my silliness isn't worth you having to go out of your way.

Suffice to say, I for one, really appreciate the work you have done and appreciate your efforts. As far as I can tell its not having any problems with reading my 980X now, the GPU readings are just icing on the cake.

Cheers

Hey guys!

I have a small issue with Realtemp 3.6 and Cpuz 1.55...

Realtemp starts up fine and everything monitors fine but when changing settings (for example ticking a box to display more than one core in the system tray) leads to a system lockup for several seconds.

This is repeatable.

With Cpuz it takes about 10-15 seconds to start up then works fine...

I suspect these issues might be related...

Os: XP x64 SP2

Question: do either (or both) of these awesome utilities require a specific runtime package to be installed or a particular .net framework version?

Thanks in advance...

Edit: Fixed the Realtemp issue with the latest C++ 2008 SP1 ATL update .... :up:

I can't tell you how pleased I am with the Turbo Boost Limits setting. Even though my Gigabyte mb has no TB adjustment beyond the normal locked number, RT 3.60 allows me to have a flexible OC with my i7 875k so the cpu multi runs from 9x to 30x, giving me a cpu speed of 4020MHz on load.

I wonder if that is a cost thing. My UD6 goes up to 64x for the 655k.

Thanks some_one for posting some graphical information to help explain how different programs report the CPU multiplier.

Biker: RealTemp is 32 bit only, doesn't use Visual C++ 2008 and isn't .NET either. I'm not sure why you were having problems but nice to hear that you got it working. I haven't done any testing with XP x64.

Quote:

---

Originally Posted by some_one

I wonder if that is a cost thing. My UD6 goes up to 64x for the 655k.

---

Is that the cpu multiplier, the Turbo Boost adjustment or the RAM multiplier? I use a cpu multi of 22x in BIOS and have Real Temp take the TB up to 30x on demand.

Next time I reboot I'll have to look at what cpu multiplier the f13 BIOS allows. Too bad the mem multi maxes out at 12x.

@unclewebb: i got a brand new 875K if you need some tests just ask me ... ;)

ps. can you provide me a link to download the latest developed version please? the link in the first page doesn't run for me ... it asks an account to fileden ... :S

RealTemp 3.60
http://www.techpowerup.com/downloads...Temp_3.60.html

Thanks for reminding me. I'll go update the link in the first post.

You should be able to have some fun with the new version on your 875K.

If you have any problems, let me know.

Quote:

---

Originally Posted by ehume

Is that the cpu multiplier, the Turbo Boost adjustment or the RAM multiplier?

---

The CPU multiplier.

CPU multiplier and turbo multiplier work from the one setting on P55-UD6 BIOS f9, at least that is when using the 860 or 655k. AFAIK all unlocked k-series use a turbo multi as the unlocked multi. For instance if you wanted to set the 64x turbo multi you just set the CPU multiplier to 64. IIRC the BIOS would then use 64x for 1 core active and 63x for 2 cores active with the 655k. Can not say for sure since I seldom used the BIOS setting.

Quote:

---

Originally Posted by some_one

it seems there is a bug in which CPU-Z interacts with TMonitor to produce garbage results. Thus I lost what little enthusiasm I had.

---

Yes this is an arbitration problem. CPU-Z and TMon use a mutex to avoid conflict, since they use the same registers to compute clocks. However, CPU-Z update is quite long, and meanwhile TMon is stuck and produces erratic data (TMon refresh rate is 20Hz, I made it as fast as possible to catch as many turbo transitions as possible).
I'm working on a fix, but it is a good idea to run TMon w/o any other clock computing program. We have lot of problems with resource conflicts, not only with other hw related programs, but also with manufacturer's tools. But we are 100% aware of those problems, so you can call back the little enthusiasm you had :D

Quote:

---

Originally Posted by some_one

It appears if TMonitor is run while SLFM is inactive it uses the LFM as a minimum threshold. If SLFM then becomes active it incorrectly shows the LFM frequency.

---

This is also a known issue, the fix will be in the next release :)

Quote:

---

Originally Posted by some_one

Another bug? :(
Core 0 thread 0 is driven on and off as above but with 1.0 second timing and run as high priority. No CPU-Z this time.

---

That one could be a bug indeed. I'll try to reproduce it. How did you generate the "square" load ?

Thanks,
Franck


Edit : maybe we should stop polluting the RealTemp topic, some_one can you please send me your email address in a PM ?

I got your PM some_one, but when I try to reply I get the following message :

The following errors occurred with your submission:
some_one has chosen not to receive private messages or may not be allowed to receive private messages. Therefore you may not send your message to him/her.

Anyway :
I compiled a new version that shoud fix some issues, especially the wrong SLFM frequency. If you can give it a try, let me know if things are better.

http://www.cpuid.com/medias/files/so...nitor_1031.zip

Thanks for the help.

Franck

I don't use XS enough to make good use of PM so I've left it disabled.

Okay, one more time. ;)

Here are the results using 1.031 with 0 performance states and driving core 0 (Thread 1 on TMonitor) with 0.5 second pulses driven by software to 9x and 3x(SLFM)/idle. Although the problem of reporting the incorrect frequency/multi when started in non SLFM and subsequently switching to SLFM is fixed, as can be seen Thread 2 although idle mimics the change in speedstep on thread 1.

http://img99.imageshack.us/img99/4166/slfm.gif



IMHO I still think it might be better without the false idle multi and I feel that would also solve a lot of problems for TMonitor as long as the users understand what TMonitor is measuring. I have modified the RealCore EIST graph to work in TMonitor mode, at least that is what I assume to be how TMonitor would work. The Multi at the bottom is still calculated using the Intel method of only counting while the core is running.

For testing I have used Load Tester which is a utility available in the RealTemp package. The users of RealTemp can also use this utility to do their own testing. EIST is disabled and the C2D is running both cores at the IDA 9x multi. Load Tester has been set to run only on core 1 using the affinity setting in taskmanager. Use of c-states means the package can still transition through the LFM during idleness.

http://img826.imageshack.us/img826/9892/70082169.gif

You can see with RealCore EIST the active running multipliers are shown however it makes it difficult to see which core/thread is doing the work. That is much easier to see with the RealCore TM-Mode (TMonitor mode). As long as the CPU is running 100% during the sampling period this should give good results however when running less than 100% active the results can be ambiguous.

EIST mode and TMonitor Mode deliberately show two different things. EIST mode shows an average of clocks/multi's for the time the CPU is running. TMonitor mode shows an average for clocks/multi's for the time the CPU running and stopped. For example if during a sample one core ran for 50% at 20x and was stopped for the other 50% then EIST would show 20x while TM-Mode would show 10x.



This next ss shows RealCore TM-Mode using a 1000x per second sampling rate to monitor TMonitor. 4 sample periods are shown to take 216ms, 54ms per sample.
http://img826.imageshack.us/img826/453/216y.png

The curious thing here is that TMonitor seems to be using ~4ms of processing time per thread and then waiting 50ms before the next processing time. Now idk if the idea is to only calculate the 50ms in between the processing so as to remove the processing use from the equation but in this case it results in an actual sampling period of 54ms or ~18.5x per second sampling. The other question is does the timer stop during the processing and what happens if a context switch occurs during that 4ms of processing. Not really asking for answers here, just some thoughts. The other wierd thing is that the graph output of TMonitor seems to update once every ~30ms and therefore appears out of sync with the sampling.



This next ss shows the effect of clock modulation (throttling) with an i7-860. RealTemp can be used to set clock modulation if you want to try this yourself.
http://img713.imageshack.us/img713/5610/fin.gif

While 50% clock modulation is taking place the processor is started and stopped in the order of some microseconds and as can be seen RealCore EIST will report the running multiplier over the sampling period while TMontior will show an average including the time the CPU is stopped.

Well I imagine I've bored everybody enough by now if not earlier but hopefully this helps explain differences in multi's read from different applications.

guys, where i can get the realcore and tmonitor features?

I think some_one's RealCore program is only intended for his own use but maybe you can twist his arm and get him to share. I don't think he has the time to polish his testing tools up and make them perfect for every CPU Intel ever built. If I ever get bored, maybe I'll have to copy his idea and create my own tool. A monitoring window like that would be an interesting feature to add to i7 Turbo.

Quote:

---

Originally Posted by unclewebb

I think some_one's RealCore program is only intended for his own use but maybe you can twist his arm and get him to share. I don't think he has the time to polish his testing tools up and make them perfect for every CPU Intel ever built. If I ever get bored, maybe I'll have to copy his idea and create my own tool. A monitoring window like that would be an interesting feature to add to i7 Turbo.

---

Good idea, why don't you get bored, LOL. A small detachable monitoring widow (maybe resizable as wide as windows gadgets) would add a good value to RealTemp. While you are on it, make sure it monitors 12C/24T too.

@unclewebb: Showing the average temperature of all the cores would be a great addition to RealTemp. An example, I can choose any of the or all 4 cores of my I7 920 to show temperatures output onto the System Tray using the System Tray Settings on the RealTemp, my idea would be to divide the temperatures of Core 00 + Core 01 + Core 02 + Core 03 / 4 = average temperature of the processor as a whole.

Quote:

---

Originally Posted by Metroid

@unclewebb: Showing the average temperature of all the cores would be a great addition to RealTemp. An example, I can choose any of the or all 4 cores of my I7 920 to show temperatures output onto the System Tray using the System Tray Settings on the RealTemp, my idea would be to divide the temperatures of Core 00 + Core 01 + Core 02 + Core 03 / 4 = average temperature of the processor as a whole.

---

i think it would be better to just show the hottest one.

The majority of temperature sensors that Intel uses on their CPUs are not accurate. With a Core i7-920, you're best off viewing core 0 since it tends to be the most accurate core.

Quote:

---

Originally Posted by unclewebb

The majority of temperature sensors that Intel uses on their CPUs are not accurate. With a Core i7-920, you're best off viewing core 0 since it tends to be the most accurate core.

---

yes you have said this before and I think it is the best advice. :up:
But I think showing to hottest core would be better than "average" of 4 cores.

From the screen shots I've seen, Core 0 of an i7-920 is almost always the hottest during normal use. When you have 4 cores side by side within 2cm of each other, its very difficult for one core to be significantly hotter than any of the others. Any difference doesn't last long as heat from one core gets transferred to its cooler neighbor. From the docs that I've seen, I think Intel agrees that these CPUs are getting so small that individual core temps aren't as important as they used to be. Starting with Sandy Bridge there is a new register that has information about the temperature of the entire package. That might be useful data instead of 6 inaccurate sensors like the Core i7-980X uses where all the cores tend to report something different.

On the Core i7-920, I can't remember ever seeing a screen shot when stress testing where core 3 was ever reported hotter than core 0. Maybe someone could run 2 threads of Prime95 and lock them both to core 3 using Set Affinity... and leave the other 3 cores idle to prove me wrong. :)

It might be interesting to see how the heat transfers from one end of the CPU to the other after it has had a minute to stabilize.

Not sure if I got this right but....

I also grabbed the 32bit by mistake, will try and get 64bit.

edit:here is 64bit. Looking at Max temps they go down from core3 to core0. Core 0 is normally the hottest core on all my bloomfields, as you said.

http://img207.imageshack.us/img207/673/p952.png

Uploaded with ImageShack.us

idle temps

http://img707.imageshack.us/img707/9342/normaltemps.png

Uploaded with ImageShack.us

Awesome program dude! Thanks!

Thanks to OC Nub, I added an option to display the highest core temperature in the system tray as a single icon. This feature has only been added to the GT version so far but I'll also be adding it to the regular version of RealTemp in the near future. If you are the type of person to lock a couple of threads of folding@home or similar to a single core then this might be a useful feature.

Edit: RT 3.61 GT needs a bug fix. I'll post 3.62 in a day or two.

Thanks for the update.

3.62 ?
:shrug:

I'm gonna be shot for this, but... Considered compiling a MAC version? :)

I don't have access to any MAC hardware or a C++ compiler so I don't see a MAC version any time in the near future.
Never hurts to ask. :)

I haven't got around to uploading 3.62 yet. Maybe tomorrow.

Will realtemp GT also support for sub-zero temps? Cause now it just shows minimal -17degrees.

It isn't possible. RT is only software and software isn't playing any rule in temp rang. It's HW (sensor) limited. Why are XOCers using thermometer instead of SW? Because there's no way to make some software to read something which HW doesn't support.

In theory, RealTemp can go as low as -27C but that's only if the on die temperature sensors don't get stuck. Most of them get stuck long before this point and even if they are not stuck, they are not very accurate when you are using them so far away from the Intel calibration point. Intel designed these sensors for semi-accurate thermal throttling and thermal shutdown control. For that purpose, they work great but they were never designed for accurate sub-zero temperature reporting.

Too bad, but the temps shown in the bios does shows sub-zero temps (GA-X58A UD7 rev.2), I thought it was the same tempsensor as realtemp.
Isn't it possible to use the same reader in realtemp?

RealTemp just reads the core temperature sensors. I think Everest or SpeedFan can read the CPU sensor that the bios reads.

I think something is not ok with my CPU temps i use RT 3.6 and it show like ~23-27 C and my mobo soft and bios show ~35-39 :confused:

It is not possible for CPU to be under ambient on air right ?

System is from signature.

What are the temps in load?
Idle temperatures are known as wrong...

Quote:

---

Originally Posted by Bullet92

What are the temps in load?
Idle temperatures are known as wrong...

---

@ Load are ok, so i gues we have to blame Asus again :mad:

No. Asus has nothing to do with that. CPU is the one you should blame because of it's core sensors. Nothing unusual for 32nm sensors.

Intel's 32nm temperature sensors are only designed and calibrated to trigger thermal throttling and thermal shutdown.
At low idle temperatures, far from the calibration point, they are completely inaccurate. The 45nm Core i7-920 used much better sensors.

Quote:

---

Originally Posted by Bullet92

No. Asus has nothing to do with that. CPU is the one you should blame because of it's core sensors. Nothing unusual for 32nm sensors.

---

Quote:

---

Originally Posted by unclewebb

Intel's 32nm temperature sensors are only designed and calibrated to trigger thermal throttling and thermal shutdown.
At low idle temperatures, far from the calibration point, they are completely inaccurate. The 45nm Core i7-920 used much better sensors.

---

Ok thanks :up: it was my first 32nm

what is different between normal and GT? where to download GT latest?

GT is for Gulftown.