Well, there is screenshot including SetThread window, which seems to also lose two cores. As I said, tomorrow I'll try 3.05 onto Server 2003 machine at work and see what happens.
Printable View
Well, there is screenshot including SetThread window, which seems to also lose two cores. As I said, tomorrow I'll try 3.05 onto Server 2003 machine at work and see what happens.
@Nevrsadie ( reply to post http://www.xtremesystems.org/forums/...postcount=3237 )Quote:
Originally Posted by Nevrsadie
sorry i deleted the large img links when QUOTE your post hope not a problem ?
i see probably the the same temperature jumps when run Prime95 (v26.8) testing BLEND mode
well, i have never paid much attention to this, mostly keep eye on max load temps,
but just as far i understand, there is nothing that refers to Realtemp i guess?
here two screens:
http://img26.imageshack.us/img26/703...3639pg3.th.pnghttp://img156.imageshack.us/img156/5...3817ou8.th.png
all monitoring programs will detect this periodic jumps
IMO this is more related to Prime95 itself how it loads cores,
... as you see
i opened 'Everest' stability test window' (built-in) only monitoring mode just for draw the graph
and set it to read data interval 1 sec for both (temp mon. graph and Load graph)
i run Prime blend approx 10 min ( see the time stamp on prime) worker-threads
explaining, - on my screens - just don't mind the 5C difference in readouts from
RealTemp 3.0 vs Everest and CoreTemp readouts -
those are just softwre side default setings i was using, and specific to hardware detection in each software, -- long story short :
using QX9650 -- RT3.0 def. use tjmax 100C ; Everest (autodetect 95C) & CoreT 99.5 also 95C
and this is not an issue, also as you see my quad have different load temps on pair of dies -
something like first pair(core: 0;1) are always higher approx 8~12C degrees
than (core: 2;3) from second pair ... does not matter ... ''jumps'' are seen also there
Add/edit
just a second run all same setup .. Prime95 SmallFFT mode:
http://img18.imageshack.us/img18/790...1634vg7.th.png
it draws a quite strait line on graph.. no jumps in Prime smallFTT testing ..
I've tried to run RT 3.05 onto Server 2003 system, but it doesn't work due of lack of CPU support : Xeon 3.4GHz, 90nm. So, I can't find out if it's a bug which affect server type operating systems only.
Unclewebb:
I think I found some sort of bug somewhere.
I noticed when I run my QX9650 at stock 3 ghz, running quad prime or Linpack shows load at 98-99% in Realtemp (linpack varies of course but goes up to 98%). But when I run it at 4 ghz, Realtemp shows load for prime at about 74-76% and the same goes for Linpack (max around 76%)
Any idea what's going on here? I couldn't find anything in the search...
darkzone: That 3.4GHz Xeon is based on the Pentium 4 architecture so it doesn't have the on chip temperature sensors that are needed. I'm taking a break on this project for a few days but will be back with some better fixes.
Falkentyne: There was a bug early on that using the Task Scheduler would set the RealTemp priority level one notch too low which would screw up RealTemp when running Linpack but Prime was OK because it is at the lowest priority by default. I know there are still a couple of bugs in the Load code so I'll be looking into improving that in the next beta as well. I might have to increase the priority of the Load code so other programs don't block it from calculating an accurate reading. I'll send you a test version in a few days.
Hey guys, I was running Real Temp 3 and CPU-Z at the same time, when I noticed something weird. See my attachment.
Which reading is correct?
I have found CPU-Z to read the bclk and multi funny at times when EIST is on. RealTemp seems to be correct as it reads the multi and speed better.
Interesting. I am running with all power saving features on + HT + turbo.Quote:
Originally Posted by Renegade5399
Edit: I tried the new version of CPU-Z (1.50) and its behaviour hasn't changed.
Uncle has hard times to get proper readings for i7 so I'll bet all my moneys on RealTemp. :D
Realtemp is correct. CPU-z 1.5 and 1.49 have problems properly reporting C1E, Speedstep and Turbo clock speeds on the Core i7.Quote:
Originally Posted by Bludd
Thanks. I sent an email to the CPU-Z dev. Hopefully, he's aware of it and it'll be fixed. :)Quote:
Originally Posted by 003
RealTemp reports an averaged multi at idle. If you are using Speedstep and have that properly enabled within your bios and within the Windows power management settings, a Core i7 will show a steady multi of 12.0 at idle. If you don't have those items set properly in your bios and within Windows, RealTemp will show an average value that floats somewhere between 12.0 and your full Turbo multi. If you want it to be steady at the full number then you have to set your bios and Windows accordingly. Turn off C1E and Speedstep in the bios and make sure your Minimum processor is set to 100% in the Power Management section of the Control Panel.
When RealTemp reports 16.0 that is a sign that the multi is constantly changing between 12.0 and your full multi.
16.0 represents the average.
Quote:
Originally Posted by 003
Try CPU-Z 1.50.1Quote:
Originally Posted by Bludd
Thanks for the information. XP doesn't let me explicitly set any processor power management. I can choose between Always on, home/desktop, max battery etc.Quote:
Originally Posted by unclewebb
Thank you. It has the same behaviour as 1.49 and 1.50Quote:
Originally Posted by stasio
In XP if you want Speedstep to work properly, you might have to set your Power schemes to Portable/Laptop in the Power Options section even if you have a Desktop CPU.
Not all motherboards are the same and sometimes C1E and Speedstep might fight each other so you will need to play around with all of these settings to get the multiplier at idle that you want. Overclocking also effects what multiplier you end up with.
Reporting the correct multiplier is a matter of opinion. It can change 101 or 1001 times a second and waking up a core to ask it what multiplier it is at can change what it reports. My averaging method is based on the Intel Turbo white paper. To keep it from jumping around too much, I decided to average the multi to the nearest half (0.5)
At full load, CPU-Z and RealTemp should show the same thing for the multiplier but at idle when the multiplier is constantly going up and down depending on your settings, CPU-Z reports a maximum amount which Intel agrees with. I decided to show an average amount because I think that better represents what's going on when Speedstep isn't set up properly.
Cool, you learn something every day. I set it to laptop and now I see 12x in RealTemp when it's idle.
Huh? What do you mean by SpeedStep not being set up properly? I thought it's either on or off.Quote:
Originally Posted by unclewebb
Unlike C1E, Speedstep can be regulated by the OS. I believe that is what the minimum and maximum processor states refers to. If you disable EIST those options probably won't show up in Power Management.
So, I know this is off-topic, but since the conversation is going this way I thought I'd ask anyway - which state will lower the multi without augmenting the core voltage, but will still respond correctly when the CPU is put under load - is that C1E? I wouldn't mind my CPU downclocking itself when I'm not loading it.Quote:
Originally Posted by randomizer
Once you manually set vcore, neither C1E nor EIST will affect the core voltage anymore. Currently on bios F6a on extreme, EIST has no affect on the multi (using regular desktop power scheme) but enabling C1E you will see the multi/mhz drop. Also, by enabling C1E the idle amps and TDP/watts drops from 33W/23A to 26W/19A or roughly 20%, whereas EIST enabled there is no drop in watts or amps. However, if I remember correctly on earlier bioses EIST would affect multi to some degree as well, or at least with earlier programs.
I think different motherboards and different bios versions handle C1E and Speedstep differently. That's why I let RealTemp report the average multi. Sometimes your multi will be doing a dance which most other software seems to ignore.
I'm back using mfc42.dll / mfc42u.dll again which every computer has multiple copies of installed somewhere. There should be no more dll file not found errors.
The RealTemp - RivaTuner plugin has been tweaked and should show a steadier Load meter. The MHz and Load were having a fight before.
http://www.fileden.com/files/2008/3/...507/RTCore.zip
You can either manually install these files into the proper RivaTuner directories but the easy way is to copy these files into your RealTemp folder, start up RealTemp, click on the Settings button, click on the RivaTuner button, click Cancel, click RivaTuner a second time, find your RivaTuner.exe file, click OK and the new version should be installed and will over write any previous versions. It takes me longer to type how to do it than to actually do it.
Actually it was more easier for me to copy these files into Riva Tuner directory ;) And into Real Temp 3.05 directory as well, but either that way hasn't run.
darkzone: Did you copy RTCore.dll into your RivaTuner plug-ins directory and select it in RivaTuner? This plug-in works fine on my Q6600 and burebista gave it a thumbs up as well on his Dual Core. It's not jumping around like it used to.
I can understand if RealTemp 3.05 doesn't work on your system, that's a work in progress but I can't understand that the new plug-in doesn't show anything on your computer.
Yes, I did ... now :D Sorry, I didn't notice that I messed up previous installation of Riva Tuner. After reinstall everything works just fine, but ... plug-in shows only two cores instead of four.Quote:
Originally Posted by unclewebb
My system still regulates vcore (I know C1E does it, not entirely sure about EIST) when it's been increased :DQuote:
Originally Posted by rge