Real Temp - New temp program for Intel Core processors

[ehume]

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.

[some_one]

I wonder if that is a cost thing. My UD6 goes up to 64x for the 655k.

[unclewebb]

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.

[ehume]

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.

[KURTZ]

@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

[unclewebb]

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.

[some_one]

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.

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

[cpuz]

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

[some_one]

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.





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.



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.


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.


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.

[KURTZ]

guys, where i can get the realcore and tmonitor features?

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

[Sam_oslo]

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.

[Metroid]

@unclewebb: Showing the average temperature of all the cores would be a great addition to RealTemp. An example, I can choose any of the or all 4 cores of my I7 920 to show temperatures output onto the System Tray using the System Tray Settings on the RealTemp, my idea would be to divide the temperatures of Core 00 + Core 01 + Core 02 + Core 03 / 4 = average temperature of the processor as a whole.

[werdwerdus]

@unclewebb: Showing the average temperature of all the cores would be a great addition to RealTemp. An example, I can choose any of the or all 4 cores of my I7 920 to show temperatures output onto the System Tray using the System Tray Settings on the RealTemp, my idea would be to divide the temperatures of Core 00 + Core 01 + Core 02 + Core 03 / 4 = average temperature of the processor as a whole.

i think it would be better to just show the hottest one.

[unclewebb]

The majority of temperature sensors that Intel uses on their CPUs are not accurate. With a Core i7-920, you're best off viewing core 0 since it tends to be the most accurate core.

[werdwerdus]

The majority of temperature sensors that Intel uses on their CPUs are not accurate. With a Core i7-920, you're best off viewing core 0 since it tends to be the most accurate core.

yes you have said this before and I think it is the best advice.
But I think showing to hottest core would be better than "average" of 4 cores.

[unclewebb]

From the screen shots I've seen, Core 0 of an i7-920 is almost always the hottest during normal use. When you have 4 cores side by side within 2cm of each other, its very difficult for one core to be significantly hotter than any of the others. Any difference doesn't last long as heat from one core gets transferred to its cooler neighbor. From the docs that I've seen, I think Intel agrees that these CPUs are getting so small that individual core temps aren't as important as they used to be. Starting with Sandy Bridge there is a new register that has information about the temperature of the entire package. That might be useful data instead of 6 inaccurate sensors like the Core i7-980X uses where all the cores tend to report something different.

On the Core i7-920, I can't remember ever seeing a screen shot when stress testing where core 3 was ever reported hotter than core 0. Maybe someone could run 2 threads of Prime95 and lock them both to core 3 using Set Affinity... and leave the other 3 cores idle to prove me wrong.

It might be interesting to see how the heat transfers from one end of the CPU to the other after it has had a minute to stabilize.

[OC Nub]

Not sure if I got this right but....

I also grabbed the 32bit by mistake, will try and get 64bit.

edit:here is 64bit. Looking at Max temps they go down from core3 to core0. Core 0 is normally the hottest core on all my bloomfields, as you said.



Uploaded with ImageShack.us

idle temps



Uploaded with ImageShack.us

[SandyTunnel]

Awesome program dude! Thanks!

[unclewebb]

Thanks to OC Nub, I added an option to display the highest core temperature in the system tray as a single icon. This feature has only been added to the GT version so far but I'll also be adding it to the regular version of RealTemp in the near future. If you are the type of person to lock a couple of threads of folding@home or similar to a single core then this might be a useful feature.

Edit: RT 3.61 GT needs a bug fix. I'll post 3.62 in a day or two.

[BobyTT]

Thanks for the update.

[stasio]

3.62 ?

[NaMcO]

I'm gonna be shot for this, but... Considered compiling a MAC version?

[unclewebb]

I don't have access to any MAC hardware or a C++ compiler so I don't see a MAC version any time in the near future.
Never hurts to ask.

I haven't got around to uploading 3.62 yet. Maybe tomorrow.