Real Temp - New temp program for Intel Core processors

[Titus]

good to see another 'official' release...

[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.

[Titus]

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

[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.

[werdwerdus]

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.

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

thank you

[Brama]

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.

[donmarkoni]

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

Thanks unclewebb!

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 out of your CPU if you have a private nuclear powerplant as a power source.

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

[unclewebb]

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.

[cpuz]

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
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

Anyway ...

[unclewebb]

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

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.



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.

[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.

[unclewebb]

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.

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.

[rge]

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???

[ehume]

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.

[cpuz]

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.

[rge]

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

[cpuz]

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.

[some_one]

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

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

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

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.

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?

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.

[ehume]

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?

[rge]

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. 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.

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.

[some_one]

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.






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.






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.

[bratboy]

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

Again thanks for the update.

[unclewebb]

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.

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.

[bratboy]

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

[Biker]

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 ....