Real Temp - New temp program for Intel Core processors

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.