It shows up fine in 3.37
http://i176.photobucket.com/albums/w...50_is_back.png
Printable View
It shows up fine in 3.37
http://i176.photobucket.com/albums/w...50_is_back.png
hmm I am working on a Dell Desktop [optiplex gx620]
and when i run Realtemp I get an error that this CPU is not supported:shrug:
Its a Intel Pentium D
I will try to make a screenshot later today
Probably the internal suckage sensor alert ("Warning - Netburst detected. Shutting down immediately.")
:ROTF: :sofa:
ah i feel stupid :D
Thanks for posting that randomizer. One less thing to fix today.
If your friend is curious, he can try running this program:
http://www.fileden.com/files/2008/3/...7/CPU_Name.zip
http://img25.imageshack.us/img25/5638/cpuname.png
It just reads the name string from each core of a CPU so his Quad should show the same string of info for each core. RealTemp 3.00 was probably just having a bad day. I think it's very rare for this info to be missing from any of the cores.
Tell him to read page 150 to look for ways to get his GPU temps working correctly.
What is "TM Load" used for exactly?
Good question. The original RealTemp load meter was based on the percentage of time the CPU is running in the C0 state. This is documented for the Core i7 and I found it gave great results on my E8400 as well so that's why I originally decided to use it.
On a Core 2 mobile CPU that supports deeper C sleep states, the C0% number actually goes up significantly as the CPU idles down and no longer represents CPU load. My best guess is that in this situation, as the CPU idles down and the cores start to go to sleep, a CPU has to start spending a bigger percentage of its awake time in the C0 state to get the background tasks taken care of. I've seen this meter report as high as 70% on a mobile chip during this situation. Kind of odd but this high number is actually a good sign. It shows at idle that your CPU is mostly asleep, which is a good thing, and it's running very efficiently.
No one ever complained but most laptop owners probably don't like seeing a 70% load number when their CPU seems to be idle. If you have that problem and don't like it then you can use the TM Load option which calculates the CPU load using the same Windows function that the Task Manager uses to calculate load.
I prefer the original RealTemp method because it is more efficient and more accurate, especially in XP, as long as you're not using the deeper sleep states. On a Core i7 or i5, I'm not sure how the two meters compare. It might depend on whether you have C3/C6 and C-States enabled in the bios.
Informative post, uncle. I'm not sure I'd be too happy seeing my laptop at 70% when it's idle. It's one of those things that irk you when you know they shouldn't heh.
i ran core temp and this one and both were displaying same temps...
@unclewebb: I'll tell him to take a look at that program, thanks.
I've heard plenty about C3/C6 states, but what about C7? It doesn't seem to get much of a mention anywhere. My BIOS allows me to limit how deep a C-state the CPU will go, and I can limit it to C1 through C7. I can also demote C3/C6/C7 requests to C1, or C6/C7 to C3 "based on uncore auto-demotion information" if I want to, although I'm unsure why I would.
punkrockpolak: As long as you understand what the C0% meter is telling you, it can be useful on a laptop. For comparison, I have a T7200 that shows a C0% number of 10% when the CPU is idle. It idles at (6.0x166MHz) 1000 MHz.
A more modern P8400 supports Super Low Frequency Mode (SLFM) which means the multi can drop down to 3X at idle so that's equivalent to (3.0x266MHz) 800 MHz. It also supports a feature where internally, it can ignore half the clock pulses so it's really only running at 400 MHz. It can use C3/C6 which the T7200 I have doesn't support so when a P8400 idles down, it has to work like hell when it is awake to process the background tasks because it is effectively running so slow and is going into sleep mode half the time. The Task Manager load meter will show 0% or close to it when this is going on but that's only telling part of the story. The C0% might be up in the 60% range on a P8400 which at least gives you some idea of what's really going on inside the CPU. I think both load meters tell you something so I included both of them.
randomizer: I was helping a user the other day and suggested that he should try enabling C3/C6 so his multiplier could reach its highest value. He wasn't planning to overclock the BCLK so I thought this might give him a little boost in performance. He didn't like it.
He thought his system felt less responsive. On his i7-920, enabling C3/C6 allowed his average multiplier to go from 21.0 to 21.3 while running a single threaded bench like Super PI. 133MHz BCLK x 0.3 is only equivalent to a 40 MHz boost. Not only did he not see an increase in performance, he was losing performance in Super PI. He seemed to have a lot of Vista baggage interfering with his testing but even best case, you're not going to see a huge difference in performance if your multi is only changing by an average of 0.3.
I haven't played with C7 so I can't say what the results would be. You might save a tiny amount of power and maybe your cores will idle a degree cooler. :shrug:
It's up to each user to test these things out and see if they provide any benefit. When overclocking, most motherboards don't drop the core voltage at idle so a lot of these power saving features are not that useful for the typical XS reader.
After running SuperPi with Affinity set to CPU 0 and all major background tasks either killed or set to CPU 0 only I still only managed to reach 21.8x with my i7 920. The other threads were usually managing a C0% of <3%, some consistently <1%. With unaltered affinity (except for SuperPi to prevent load balancing) it typically doesn't break 21.4x. Turbo might be useful for a single speed bin increase on LGA1366 but it certainly doesn't do much better than that.
randomizer: Could you try another comparison? I'm interested to see what's better without changing the Affinity of any of the background tasks and without killing any of them either. More like how the average person has their computer set up.
In this condition, is it better to use Set Affinity.. and manually lock Super PI to a single thread or core or is it better to leave Set Affinity... alone and allow the CPU to manage this and let it move Super PI to whatever thread it wants? What's your estimate of the average multiplier in each case? On a Core i7 with hyper threading enabled you could allow Super PI to run on the first two threads since they usually both belong to Core 0 as long as RealTemp is showing that your APIC ID as 01234567.
The new socket 1156 CPUs that have 4 or 5 bins of turbo boost available get more out of leaving C3/C6 enabled so the CPU can use the highest multiplier. The Core i7-9xx series processors that can only average an extra multiplier boost of 0.3 or 0.4 beyond the +1 turbo boost isn't really worth while. I assume that's why most performance motherboards disabled this extra boost as soon as you start overclocking. Better to have it locked at a steady 21.0 than jumping between 21.0 and 22.0 which is likely to cause instability when overclocking.
Hey Kevin,
now everything looks normal :)
http://lab501.ro/forum/attachment.ph...1&d=1256059381
A 32nm hyper threaded dual core looks like fun. I hate heat and fan noise so this finally looks like a CPU I'd like to have; once all the Foxconn sockets are off the market.
RealTemp still needs to call your new CPU a Core i5 instead of a Core i7 but at 4.7 GHz, who cares? :D
I think I fixed that minor bug in version 3.37 or 3.38
http://img14.imageshack.us/img14/4531/i5650.png
http://www.fileden.com/files/2008/3/...alTempBeta.zip
The significant difference in core temperature at full load while running Prime 95 Small FFTs looks like more evidence that Intel "accidentally" sets TJMax slightly higher on core 1 compared to core 0 to better control thermal throttling. ;)
I hope they admit to that someday. Thanks for sharing.
Bwhahahah! Now I will try 3.38, thx Kevin.
Edit - Uf, it says 3.37 :(
Anyway, the i7 bug is solved. Here ya go:
http://lab501.ro/wp-content/uploads/2009/10/RT-338.jpg
Thanks for showing me that. I thought I fixed that but I lose track sometimes. :)
There's no major difference between 3.38 and 3.37 so you're not missing anything important. It was some minor adjustment for a mobile CPU. I think I uploaded it to SendSpace instead of my regular FileDen.
To accurately gather data from your computer, RealTemp and i7 Turbo need to be able to access all of your cores. Adjusting them with Set Affinity... isn't a good thing to do. The log from RealTemp might be your best bet when gathering some data. I need to update the logging abilities of i7 Turbo so it gathers and saves data for each thread. I'm not looking for a super scientific test. Just some numbers. A multiplier difference of 0.1 or 0.2 isn't something a person would ever notice in normal use. If we need a more scientific tool, I'll tune up i7 Turbo with some better logging abilities.
Thx stasio!
Yep, but you have one constant value: distance to TJMax. That's why I keep telling that temperature related with TJMax is irrelevant as long as the only value that's matter for your CPU thermal behavior is distance to TJMax.