Real Temp - New temp program for Intel Core processors

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