Real Temp - New temp program for Intel Core processors

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

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

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

[cpuz]

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

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

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 ?