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.