msconfig -> boot tab -> advanced settings...
http://forums.extremeoverclocking.co...5&d=1201937581
Check out what it says for number of processors. Try unchecking it if it's checked, or vice-versa.
Printable View
msconfig -> boot tab -> advanced settings...
http://forums.extremeoverclocking.co...5&d=1201937581
Check out what it says for number of processors. Try unchecking it if it's checked, or vice-versa.
That box is unchecked, Kevin told me to leave it so. I'll try tonight to check it and see what happens.
checking the box and selecting a number tells the OS how many CPU's to enable.
I just tried setting this to 2 and my Q6600 Quad instantly became a Dual Core according to Vista.
The TaskManager only shows two cores as well.
http://img253.imageshack.us/img253/6598/castrated.png
Usually when Number of processors is unchecked, the operating system defaults to using all available processors.
Maybe if you set your OS to 4 darkzone, all programs might be able to see all 4 cores.
Edit: I noticed that when Core Temp only sees two cores it thinks I must have swapped my Q6600 for an E6600. :)
http://img9.imageshack.us/img9/1647/coretemp.png
Well, the problem is deeper than I thought ... :( Checked or unchecked, 2 cores, 4 cores, it seems doesn't have any effect. So, must dig more deeper :D
burebista noticed some instances when the load reported by the RivaTuner / RealTemp plug-in was significantly different than the built in RivaTuner CPU.dll plug-in and asked me to come up with an explanation. The RealTemp method of calculating load is different than the traditional method so I was curious too of which method is the most accurate. Here's what I found during testing.
I decided to run 4 threads of Prime95 Small FFTs so the RivaTuner CPU.dll plug-in was showing 100% for all 4 cores and the RealTemp RTCore.dll plug-in was showing an average of about 99%.
I stopped Prime95 so the load instantly returned very close to 0%. I went back and did some screen captures which shows the results during this rapid load transition.
Time = 13:46:00
http://img12.imageshack.us/img12/6704/image00.png
CPU.dll is reporting 100% for all 4 cores while the RealTemp plug-in is already down to 57.1%
Time = 13:46:01
http://img12.imageshack.us/img12/6990/image01.png
The Riva CPU.dll plug-in is showing an average of 29.89% while the RealTemp plug-in is already correctly reporting 0.1%
Time = 13:46:02
http://img239.imageshack.us/img239/1990/image02.png
Exact same as last second. The Riva CPU.dll plug-in is still reporting an average of 29.89% while the RealTemp plug-in is at 0.1%
Time = 13:46:03
http://img239.imageshack.us/img239/7666/image03.png
Finally the RivaTuner CPU.dll plug-in has caught up to the RealTemp plug-in.
My conclusion based on the above is that the RealTemp RTCore.dll plug-in is much faster and more accurate at correctly reporting the load during rapid load transitions.
I don't think the RealTemp RivaTuner plug-in is always 100% accurate but in some situations I think it is more accurate than the TaskManager Load meter as well as other load meters based on similar code.
Edit: During the early part of this test I was using the Clock Modulation feature to adjust the Load. Traditional Load meters will continue to report this as 100%.
Hi Unclewebb,
last week, I made a post asking about the 'load' issue in Realtemp.
The issue was that as the cpu speed gets higher, the load % seems to slowly decrease in realtemp.
I'm using a QX9650 and P5WDH board. either 2x2GB Ram or 1x2GB.
At 3 ghz (333x9)=default speed, Realtemp shows load of 99% with Prime 25.5 running.
At 3.7 ghz (370x10), realtemp shows load of 89%.
At 4 ghz (333x12), load is 74%. (same thing happens under Linpack when it gets to maximum stress, btw).
I forgot what it was at 4.1 ghz but it was in the high 60's.
Task Manager shows all 4 cores at 100% usage and process prime95 at 99%.
I actually noticed this problem many months ago but never thought about reporting it.
These tests were all after a fresh boot, with nothing running except necessary windows services, Prime95, Realtemp and CPUZ.
I tried the 3.06 beta and same problem.
You mentioned something in the other post about it but I didnt really understand it.
Falkentyne: I don't yet know if your problem is a RealTemp problem or maybe a problem with your CPU when overclocking. The number of people that have reported problems with the Load meter is very limited and during my testing when running 4 threads of Prime95 Small FFTs, it consistently shows in the high 99% range. When I recently did some testing for darkzone using Server 2008 HPC, on the same CPU it got as high as 100.0%. When I run 1, 2 or 3 threads of Prime, I get 25%, 50% or 75% more or less and it stays very consistently at those numbers unless something in the background kicks in and it briefly goes higher.
Use Prime95 Small FFTs when testing because I know the load it produces is very consistent. Are your percentage numbers consistent when you are running Prime95 Small FFTs? When you are overclocking to a higher MHz, does the Load meter initially start out at ~99% and then drop to 89% or 74% and then remain consistent at this amount or does it immediately only go to 74%?
There is a feature within Intel CPUs called Clock Modulation that can become automatically activated either by software or it can also become activated internally by the CPU itself. The percentage numbers you've mentioned have me wondering if maybe something like that is going on. Run Prime95 Small FFTs and go into the Settings window and you can play around with software activated Clock Modulation. The percentage numbers listed (87.5%, 75.0%, 62.5%, etc.) are Intel's approximations from their documentation. Depending on what multiplier your processor has, what you actually end up with will be different and won't equal those numbers.
My Q6600 has a 9.0 multi by default. My Load meter when playing with Clock Modulation will go from 99% to 88%, 77%, 65%, 55%, 45%,... Those first 6 steps seem to correspond pretty closely to 9/9, 8/9, 7/9, 6/9, 5/9 and 4/9. The last two steps I get are more like 3.5/9 and 2.5/9.
When Clock Modulation is activated on my Q6600, for every 9 pulses of the clock generator, 1 or more pulses gets ignored depending on how much modulation is being used. Programs like CPU-Z and RealTemp will still show your CPU running at full MHz but internally the CPU is acting sort of like a heart that is skipping a beat. This causes the CPU to run cooler since internally it's really not doing the same amount of work as a similar processor running at that same MHz which doesn't have any Clock Modulation going on.
Here's an example of my CPU at full load with no Clock Modulation:
http://img4.imageshack.us/img4/9706/load100.png
When I set Clock Modulation to 50%, that seems to be equivalent to a load of about 5/9 or 55.5%.
http://img24.imageshack.us/img24/6493/screen50.png
The Task Manager and other traditional load meters continue to report this CPU working at 100% when internally speaking, it's only working half that hard.
It's obvious that this CPU is not working as hard because the average core temperature has dropped by about 10C compared to the first picture. The Task Manager continuing to report 100% Load does not accurately reflect what this CPU is doing while in this case, RealTemp does.
Do some testing and see if your RealTemp reported Load percentages correspond closely to what you'd get if you manually set Clock Modulation.
It's possible that this is nothing more than a big RealTemp bug but it's also possible that Clock Modulation is going on internally within your processor when you are overclocking. It's just a theory but it looks like the harder you push it, the more modulation kicks in.
I'll read the documentation and see if I can find a way to read the internal Clock Modulation status of a CPU. I think the user Clock Modulation and the hardware Clock Modulation are reported in separate registers. This bug is even more interesting than the last one. :)
Edit:
Model Specific Register (MSR) 0x19A is where software Clock Modulation data is stored within your CPU. User clock modulation is stored in the lower 5 bits. The upper bits are listed as Reserved by Intel but when your processor is reporting some lower than expected Load numbers in RealTemp, try doing a Read MSR on 0x19A. I don't know if it will show us anything but it's worth a look.
You can use my MSR tool for that:
http://www.fileden.com/files/2008/3/3/1794507/MSR.zip
http://img25.imageshack.us/img25/6374/msrtool.png
You can click on the Read MSR button as much as you like and you won't hurt anything. If you enter random data into those two white boxes and go to different MSRs and click on Write MSR then you might get lucky and crash your computer. :yepp: If that did happen, after you re-booted, everything would be back to normal so no worries.
Also try turning off TM1/TM2 in the bios when testing to see if that makes any difference when you're testing.
Kevin don't forget our good ol' friend: RMClock. ;)
http://img172.imageshack.us/img172/3689/modulation.jpg
I've always liked RMClock 2.30
I tried a later version once but went back to 2.30.
I'm not sure how RMClock calculates its load percentage or if it will be able to report any internal throttling but it's worth a look.
Hi Unclewebb :)
here 2 screens on 45nm quad test on oc'ed @3600 .. 2 runs - clk modulation 50% and NO clk mod. (common state) - Speedstep/EIST - Disable
all the same as You tested on your's, probably same temperature (10~12C)drop on 50% down-clock.
also noticed that only Everest can register (partly?) this clock modulation only via its CPU (W) wattage / power usage field
just as i see - that dropping power draw ~ approx 50% during 50% clk. modulation state
http://img517.imageshack.us/img517/4787/68222557.th.png http://img13.imageshack.us/img13/387/11659490.th.png
:)
Any idea why Real Temp above 3.00 only displays 3 cores? I've tried vrs 3.05 and 3.06
Using i7 320 + gigabyte EX58 + Vista 32 bit
Attachment 95548
Attachment 95549
It does detect something it's hard to see what's happening. In fact it even gives you a popup telling you you're throttling. :D I tried it once back when I was more afraid of burning my chip up. It didn't show much but I'd say with a bit more heat it would have throttled for long enough to show something valuable:
http://i176.photobucket.com/albums/w...1/th_burn3.jpg
Man, I was still using XP back then... I like this page for showing what should be happening, albeit with an older version of RMClock and using a Prescott.
Hi Unclewebb:
I Tried the programs you mentioned and here are a few results.
At 3500 mhz:
http://img510.imageshack.us/img510/6875/3506mhz.jpg
And at 4000 mhz:
http://img23.imageshack.us/img23/6065/4000mhz.jpg
So RMclock isn't showing any throttling. MSR isn't showing anything strange either.
1 more comparison:
4000 at 50% modulation:
http://img510.imageshack.us/img510/7...z50percent.jpg
BTW the dips in the graph were when I kept stopping prime or messing with the modulation. (prime really needed 1.352v in cpuz to not error out).
i43: Thanks for your pics. Your Quad works like my Q6600 and seems to display accurate Load percentages. rge did a lot of testing on his Core i7 and also had believable looking results.
DGill: Version 3.05 was designed to try and figure out what was going on with darkzone's computer. I made 101 changes trying to understand what was going on with his operating system. I wouldn't recommend using version 3.05. If version 3.00 works for you then continue using that at the moment.
Version 3.06 was designed to fix darkzone's problem and in theory should work OK but obviously it doesn't work for you. Now that I have a clear understanding of what was causing his problem, I'll try making some adjustments and come up with a solution that works for everyone. Maybe 3.06 will become known as the darkzone version.
Falkentyne: RMClock and my MSR tool don't show anything unusual so it looks like either the RealTemp Load meter is borked on your CPU or it is telling you that there is a problem with your CPU when overclocking.
One thing I noticed comparing your first two pictures is that in the first picture your temps are 50, 41, 33, 48 and in your second picture the temps are 57, 51, 44, 54. The difference is 7, 10, 11, 6. That's very unusual. Uneven sensors on a 45nm Quad are not unusual but when running Prime95 Small FFTs and playing with the Clock Modulation or changing the MHz or core voltage, all 4 cores tend to change in temperature more or less equally. Yours don't.
burebista just asked me yesterday to include an option in the RealTemp / RivaTuner plug-in so the Load of each individual core can be displayed. I think I will work on that next because it might give us some more information about what's really going on inside your processor. Currently, RealTemp calculates the Load for each core individually, adds them up and divides by the number of cores to report the average so changing that code to draw 4 squiggly lines instead of one shouldn't be too hard. I'm interested to see if all 4 of your cores are reporting a lower load percentage or only a couple of them are.
You might be able to run a multi-core benchmark like wPrime and compare your results at 4000 MHz to another user with a similar 45nm Quad at the same speed. Run RealTemp at the same time and watch what Load it reports. Your results are either going to be very comparable to another 45nm Quad or if your processor is only working internally at 75% when overclocked to 4GHz then your results are going to be very obvious that something is wrong.
Another test I just tried was to run 5 instances of RealTemp. When the first version starts up, go into the Task Manager and set the Priority to Realtime. Use this one so it can monitor the other 4. Start up the other 4 instances and click on the XS Bench button of those 4, one after another, so all 4 are running at the same time. What does the load meter say on the first instance of RealTemp? The scores on all 4 should each be somewhere around 1330 when you are at 4GHz. With my Q6600 at 3 GHz, all of them are pretty close to 1000. This benchmark scales very linearly with MHz so it might show you if a core or two are not working at full speed.
http://img15.imageshack.us/img15/3707/bench.png
At the moment either RealTemp is wrong or the timers that RealTemp reads within your CPU are not working like other Quads do under load or your CPU is internally throttling. With some more testing hopefully we can figure something out.
Hi,
I just did a quick test at 340x10 (3.4 ghz) and the 4x xsbenches reported
1131, 1130, 1131 and 1131. Time was 12.931, 12,942, 12,940 and 12,934.
I couldn't press them all at the same time as mouse "input" seemed to freeze for a second or so after I went to press the second one.
I'm going to reboot now and try 4 ghz (333x12).
BTW about that sensor:
That third sensor barely moves.
The one that's "stuck" on 27C...
If I run quad prime at, let's say, 3 ghz, the temp doesn't even go anywhere.
However if I run linpack, the sensors get up to 69, 69, 63, 63.
In prime95, the only two sensors that seem to move properly are sensors 1 and 4.
Edit:
Just ran the 4x xsbench + 1 realtime priority realtemp, at 333x12=4ghz.
score were 1328 (11.017s), 1330 (11.003s), 1329 (11.010s), 1330 (11.001s)
Temp sensor#3 remained stuck at 27C.
#1=49C, #2=34C, #4=47C.
Going to try wprime now.
Ok wprime 32M was 10.656 secs
Trying 1024M now.
Ok i just noticed something, unclewebb.
Final score was 338.703s (lowest) and 339.516s) highest).
Cores 1 2 and 4 finished at almost the exact same time in 1024M test, but when they finished, core 3 was at 96% O_o
Um....what does that mean? O_o
RMA the CPU? >_> Or is this a motherboard issue?
I'm going to go back to 3 ghz and try it...
I will say this:
Back when the QX6700 and QX6800 was out (I had an X6800 at the time), I remember a LOT of posts about people saying that 1 "thread" in quad prime95 was lagging behind other threads, and people discussing problems with "load balancing". Now I think I know what they were talking about...But if this happened on the QX6x00's....is this a motherboard or windows problem? Or do I have to RMA the CPU?.....
1 other thing I noticed:
in RMclock,
cores 0 and 1 have a VID of 1.2375v. Cores 2 and 3 have a VID of 0.825v. WHAT? O_o....
Well went back to 3 ghz again. Realtemp showing 99-99.9% load in wprime right now, but again core3 is lagging behind the other cores slightly. So it seems that the core3 lagging problem isn't related to realtemp, as RT is showing 99% at 3 ghz?
I'm going to search XS for more posts about the lagging core problem....
BTW at 3 ghz in wprime, which is running right now, at 1.25vcore, cores 2 and 3 sensors are not moving at all (well, core 2 moved by 1C, core 3 moved by 0. Cores 1 and 4 sensors are functioning properly. Core 3 is pretty much stuck except at high vcore and load (only Linpack gets it to rise up to as much as core 4).
DGill: Version 3.05 was designed to try and figure out what was going on with darkzone's computer. I made 101 changes trying to understand what was going on with his operating system. I wouldn't recommend using version 3.05. If version 3.00 works for you then continue using that at the moment.
Thanks for the reply :up:
Unclewebb
forum was down for awhile :(
anyway, I found the problem with the load% on realtemp.
It's something to do with the multiplier.
At the default multiplier of 9, realtemp shows 99.9% load.
At multiplier of 12, it's 74%, regardless of CPU speed (FSB) used. both 266x12 and 333x12=74% load.
At multiplier of 15, it's 59%. (200x15).
And at 20, it's 49%.(i used 150x20=3ghz).
Benchmark scores are not affected by this (except much longer tests or bandwidth from using a lower fsb);
200x15 in wprime 32M gave 14.1s, same score as 333x9. Benchmark scores related perfectly to core speed.
I haven't tried going under multi 9.
Any ideas why this is happening?
BTW about the core 3 being slightly slower in wprime, seems that is more related to load balancing; I ran some "1 thread" tests (took a really long time) with affinity for the new wprime process that appeared, set to a separate core, and core2 seemed fastest, followed by core 4, 1 and 3. But at 1700 seconds, core 3 taking 10 seconds more than core 1, is not much (basically a 10 second difference between the cores finishing, at about 25 minutes).
In the 4 thread test though (which finished in 5 minutes 32 seconds) it was much more pronounced; core 3 finishing about 16 seconds after the first 3 (which finished at the same time). That seems to point to an issue with load balancing I guess....still very strange how that's happening though... 10 seconds slower at 25 minutes with single core/thread test, and 16 seconds at multithread/4 threads at 5 minutes... weird...
Man, you forgot to launch prime95 when RealTemp asked you. :)
Please do it because you have 0.1% load.
Falkentyne: I've been trying to post all morning that I think I figured out what's going on with the load meter on your computer but XS was down so I guess you beat me to it.
The method and timers that I am using are somewhat documented for the Core i7. I found they also seemed to work on most Core 2 processors so that's why I included a Load meter based off of them in RealTemp. On most Core 2 Dual and Quads like my Q6600 with a fixed multiplier the RealTemp Load meter works great. On Extreme processors that have an adjustable multiplier, it looks like I need to adjust the load meter based on what multiplier you're using compared to the default multiplier. When you are using a multiplier of 12 and your default multiplier is 9 then I think the load meter will be reading about (9/12) X 100% or ~75% when running 4 threads of Prime95 Small FFTs.
The internal timer I'm using seems to get screwed up when you change the multi on the Core 2 QX processors but I think it's fine on all Core i7 processors, including the 965 Extreme.
It should be very easy to correct for this and come up with a quick fix for you if you can help me out. The Intel documentation is like looking at Swiss cheese. A lot of information is labeled as Reserved or in other words, "Good luck trying to figure out what's hiding in this MSR." :)
Can you read a few MSRs for me with your multi locked to 12, at its default of 9 and maybe even locked to a number less than 9.
The 3 MSRs I'm interested in are:
0x17
0x15F
0x198
You can run 3 instances of MSR Tool at the same time so you'll only need to send me or post 3 screen shots. I think there should be enough information in those MSRs to take care of this problem. A 12X multi in hex should show up as the letter C in some of those MSRs when you are using that one.
The last person to complain about the Load meter had a QX6800 but I didn't put 2 and 2 together then. Using the internal timers seems to be the most accurate way to calculate the load so I'd like to get this minor bug fixed.
DGill: I kind of like the new GPU button in version 3.06 for Nvidia owners so I'll try to go back to the old way of reading cores in the next release to get your problem fixed up. Hopefully the next fix will continue to work for darkzone as well.
pra: Stuck sensors are not unusual at all at lower temperatures. Intel only designed these sensors to work at higher temperatures to control thermal throttling and thermal shut down. As long as your CPU runs OK you don't have to worry about the temperature, especially low load or idle temperatures.
Ok I have some screenshots.
x12:
http://img205.imageshack.us/img205/3...ltplier.th.jpg
x10:
http://img172.imageshack.us/img172/8...tiplier.th.jpg
x9:
http://img205.imageshack.us/img205/1...tiplier.th.jpg
x6:
http://img172.imageshack.us/img172/5...tiplier.th.jpg
Do these help?
Falkentyne: That's going to help a lot and will get me started with improving the load meter accuracy for QX owners. We might have to do a little bit of fine tuning but I should have a beta out by tomorrow for some initial testing.
Could you send me one more screen shot at x10 or x12 with Speedstep or C1E enabled? When these are enabled, does your multi drop down to 6.0 at idle like most Core 2 based processors do? I just want to make sure that I cover as many different situations as possible. So far it's looking like a simple fix is going to finally solve this problem.
Speedstep/c1E don't work on the P5W Dh board with 45nm cpu's though :(
EIST function doesn't even appear with a 45nm.
At least I could never get it to work. I think others couldn't get it working either even though it worked with 65nm cpu's. Heck I remember even when it worked, it sometimes was buggy; with my X6800, sometimes (rarely) it put my vcore at 1.15v even when it was set to 1.45 in bios... O_O, and that was with speedstep/C1E/EIST all disabled.
I'll try again though, right now...
I'll set voltage to auto, and speedstep and c1e (or TM1?) to enabled....
Um...no dice.....
Speedstep not present in BIOS with 45nm.
EIST not present.
C1E set to auto.
Vcore set to auto...
In BIOS 2406, speedstep and EIST were available but didn't do anything at all.
On 2704 (and 2801) theyre gone if youre using 45nm....
Booted in windows with C1E set to auto and auto vcore, cpu ratio adjustment disabled, and no change in voltage, multiplier or cpu speed. (vcore was 1.216v).
No problem. If Speedstep doesn't work on your board / CPU then I guess I won't have to worry about that. :)
One thing I mentioned recently is that sometimes you have to go into the Power Options in the Control Panel and with XP you need to set it to a Mobile processor to get Speedstep to work properly. On some boards this over rides any bios settings and will drop your multi to 6.0 at idle. In Vista you need to set the Minimum processor state to a low number like 50% to accomplish the same thing. RMClock 2.30 usually allows you to toggle C1E when you are in Windows but Speedstep on my board is read only. I should have time today to fix this and then you can do some beta testing to see how it works.
This is a bug fix version to try and get the load meter working properly on the QX processors when different multipliers are being used.
If I did a good job then it should also be able to find all 4 cores of DGill and darkzone.
http://www.fileden.com/files/2008/3/...alTempBeta.zip
If you have mfc71u.dll installed in C:\Windows\System32 then you can use the smaller Beta2 version.
http://www.fileden.com/files/2008/3/...lTempBeta2.zip
Falkentyne: Time for some beta testing. Try running 3 threads of Prime95 Small FFTs at different multipliers. The Load should be fairly steady at about 75% if not too much else is going on in the background. Try it at the default 9.0 multi and at a multi above and below the default. I'm pretty sure it will work when above 9.0 but not 100% sure it will work correctly when a multiplier is set to less than 9.0. It might need a tweak for the low end. Thanks for your help.
You can try 4 threads as well but I think 3 threads will clearly show if there is a problem when using lower multipliers.
If any new bugs have been created then report them too.
I Just used crystalcpuid to change the multiplier and everything was fine in realtemp. Used 6x to 10x.
I have to lower FSB to go higher ...but I think everything will be ok.
might as well try a quick 150x20....
*working fine after reboot at 150x20.
99.9% load in quad prime, 74.9% in 3 threads.
Thanks for confirming that Falkentyne. :up:
Now I just need to transfer a few new lines of code to the RealTemp / RivaTuner plug-in to get that fixed up as well for QX owners.
Works for me :)
No rush Kevin. Take your time, you know I'm patient.
Focus on main RealTemp features. :)
Quick question, on old RealTemp had to change TJ max to 95 for E8600, do i have to do same on RealTemp3.00 or just leave it at 100 :confused:
Did I just have a Crash when playing Warhead, or did Realtemp shut the computer down, I did'nt get BSOD.
Can Real temp shut down the computer, if GPU temps are too high...?
BTW Thanks for the program :up:
PRJ
oggie: Intel finally told users last year that the TJ Target for the E8x00 processors is 100C and TJMax is likely somewhere around there. I changed RealTemp to reflect that information.
The fact is that TJMax is not a fixed number. It varies from one E8600 to the next and even from one core to the next on the same CPU. That's very obvious on the 45nm Quads. Intel didn't release enough information about how much TJMax can vary so their release of TJ Target for some CPUs isn't much better than a number out of a hat. Find a number you like and check your calibration using rge's method to see if your choice or RealTemp's choice of TJMax is reasonable.
http://www.xtremesystems.org/forums/...postcount=2429
PRJ: RealTemp has the ability to shut down your computer based on an Nvidia GPU temperature. It won't do it automatically though. You would need to have it set it up more or less like this:
http://img91.imageshack.us/img91/4107/alarm.png
You would have to tell it in the Settings window to run RTShutdown.bat which runs the Windows shutdown.exe command for you. It's easy enough to edit that .bat file if you want to use some different parameters for that command or you can create your own .bat file and get RealTemp to do whatever you like. I thought I'd include one .bat file for an example.
You can turn off this feature and turn on the GPU log file and set the interval to 1 second and then go do some gaming. Once you're finished you'll be able to go back and see what are typical GPU temperatures for your setup. I liked these new features so much I went out and bought an Asus 9800GTX+ card recently to enjoy them. ATI makes it more of a hassle to read GPU temperatures so getting a different card was the easiest thing to do. :)
3.00 works fine for my old B3 qx6700. 3.06 only showed 2 cores and 3.07 only shows three cores.
Sounds like I'm making progress. :)
I intend to go back to the original code and original C++ compiler I was using for 3.00. There seemed to be a lot less of these random issues when using that. Hopefully I can add in the QX Load meter fix to 3.00 and the GPU button without screwing up anything else.
If 3.07 works on your computer then use it but if not then stick with 3.00. I might have to re-name it RealTemp darkzone because he seems to be the only one happy with it.
I think I've just found a new motto for you: complicating the uncomplicated :ROTF:
3.07 works fine for me too by the way :) QX6700 and Q9550
http://www.fileden.com/files/2008/3/...507/RTCore.zip
Just doing some initial beta testing of the updated RealTemp / RivaTuner plug-in.
http://img13.imageshack.us/img13/4496/rtplugin.png
I added the ability to view individual load data for each core/thread to keep burebista happy.
Even with the polling interval dropped down to 0.2 seconds or 5 times a second, the average data is steady with two threads of Prime Small FFTs running while the individual loads are rapidly jumping up and down just like Intel intended. When you set the polling interval back to 1 second, it should look similar to the Task Manager graphs. More accurate, but similar. :D
I should have a fresh fix tomorrow for the 3 core Quad bug that I created when fixing darkzone's issues.
I haven't tested this plug-in with a hyper-threaded Core i7 yet so give it a try. You should have more data than you know what to do with it.
Unzip the files and copy them to your RealTemp directory and then click on the RivaTuner button in the RealTemp Settings window and install them by clicking on OK a couple of times.
uncleweb how about i7920 tjmax set?
Can you translate that question to English? :)
Most of the Core i7 920 CPUs that I've seen have TJMax set to 100C if that's what you mean.
I saw in the forums yesterday that there are some new Core i7 CPUs coming out with CPUID 0x106A5 and Core Temp was showing one of them as TJMax = 92C. TJMax is contained within a register of these newer processors so a program like RealTemp or Core Temp can read that value directly and I'm pretty sure that both programs are doing that right.
If that didn't answer your question then try again.
http://www.fileden.com/files/2008/3/...alTempBeta.zip
I went back to the original 3.00 code and the old C++ compiler and added a few recent bug fixes and the GPU button to it. It includes support for the original Core i7 ES processors as well as the new ones. The 3.0x code is going into retirement.
Will the new / old RealTemp pass the darkzone test? Time for some beta testing to find out.
Unclewebb, love your work :clap: You must be proud to have made such a great application for all of us to use :cool:
Quick one if you dont mind, this 3.07 version....it works for GPU as well ?? You you please explain :confused:
Ignore above, have read through your thread and understand now
oggie: Unfortunately, RealTemp only supports Nvidia GPUs at the moment. Nvidia makes it simple to read temperature data but it's more of a hassle with ATI cards. I might add ATI support someday.
RealTemp 3.11 works well with i7. Thanks, much appreciated :up:
It seems that new version 3.11 doesn't work. Anyway, the big problem is my operating system which has an issue (I didn't found out what yet).
The missing core returns.:cool::up:
How accurate would these temperatures be considering the large distance to TjMax??
http://i669.photobucket.com/albums/v...oldowntest.jpg
Ambient is 15 degrees Celsius btw., before you guys start saying that these themps are impossible...
Running the 3.11 on a rig with Q6600 it shows load at 74% when all other programs show correct 100%??
http://img.photobucket.com/albums/v2...h_RTLoadSS.jpg
Mine looks fine. :shrug:
http://i44.tinypic.com/vd0ls1.png
Not sure about mine.
OCCT shows 99% utilisation
RealTemp 3.11 indicates 75%
& for what its worth, a Vista Gadget also shows 75%
Version 3.07 was just for you darkzone but trying to find your missing cores was causing problems for other users so I've gone back to my original code for versions 3.1x and above. There's no difference in features between 3.07 and 3.11 so run whatever version works for you.
The Load meter is accurate on my Q6600 G0.
http://img5.imageshack.us/img5/1316/rt311load.png
It should show something like the above when running 4 threads of Prime95 Small FFTs.
This load meter is based on reading timers within the CPU. If you're only getting a reading of about 75% when running the above load then it looks like it's only reading 3 of the 4 cores correctly. Why? I don't know but if you have some time to do some testing I'll come up with a version for you to try to find out what's going on. Just send me a PM and tell me you want to do some testing.
Hardass: If you have RivaTuner installed you could try using the RTCore.dll plug-in. Just go into the RealTemp Settings window and click on the RivaTuner button and tell RealTemp where you have your RivaTuner.exe file located and it will install the plug-in in the correct directory for you. It shows individual core load now so it might help me find / understand where the problem is. The plug-in is burebista approved. :)
maGSImum: It looks like your sensors are reading a little low at idle which isn't uncommon. Try running Prime95 Small FFTs with some more core voltage to get your temps into a higher range if possible. I found my Q6600 likely has a higher actual TJMax on cores 2 and 3. TJMax = 100 / 100 / 105 / 105 seems more accurate for my CPU. At higher temperatures I have a very consistent 5C difference between the two sets of cores but yours look like your 4 cores would be well balanced at higher temperatures.
The best thing to do is use rge's calibration guide lines. Your sensors are functional at high Distance to TJMax values but you can improve their accuracy by calibrating them.
http://www.xtremesystems.org/forums/...postcount=2429
Add on 1C for a Q6600 compared to his numbers.
DGill: I plan to make a separate Load utility using these timers to do some more testing of this. It's interesting that the Vista gadget is showing the same thing.
All 4 cores show 100% in RT:)Quote:
Originally Posted by unclewebb;3703220
[B
Ahh ... I see. Prime95 works fine, runs 4 cores and RealTemp shows 100% utilisaion. Presumably when I ran OCCT it only identified/used 3 cores.
Can you try running Prime 95 Small FFTs? By default, Prime95 does its stress testing at the lowest priority so your computer is still usable while stress testing and usually RealTemp doesn't have a problem reading the correct Load %. Some other load testing programs run at a normal priority which can bog things down. RealTemp might be fighting with some of these stress programs to read the timers correctly.
I've seen this issue before with LinX which is why I boosted the priority of the RealTemp / RivaTuner plug-in above normal to try to correct for this. I might have to add the same code to RealTemp 3.11 if this is the issue.
You might also be able to go into the Task Manager and lower the priority of OCCT to see if that gives RealTemp enough time to read the timers.
http://www.fileden.com/files/2008/3/...alTempBeta.zip
I boosted the priority one notch to see if that helps maintain the Load accuracy readings while running OCCT, LinX, etc. without RealTemp becoming a CPU hog. Can't have that. :)
I also put some modified darkzone code in there to try to help him without it screwing up the rest of us.
Place your vote.
Bugs Fixed: :up:
Bugs Created: :down:
No change while running F@H smp client.:(
Nope, still don't work for me :confused: Anyway, a fresh install of OS is planned when i7 940 arrives, and I'll see then if the problem is solved.
Maybe guys at TechPowerUp could help you.
http://www.techpowerup.com/gpuz/
They're the makers of GPU-Z which reads AMD cards temperature...
http://www.fileden.com/files/2008/3/...alTempBeta.zip
Here's lucky 3.13. I boosted the priority up to the same as what the RealTemp / RivaTuner plug-in uses. In theory, you shouldn't have to ever boost the priority but other programs like OCCT boost the priority of their processes which can prevent RealTemp from accurately reading the CPU sensors. When Prime95 is stressing your CPU it drops its priority level down to rock bottom so other processes can still do their thing. That's the polite thing to do when you are fully loading a CPU. If this fix works, great, if not, I probably won't change it.
If you are still having problems then you can use the Task Manager and right click on RealTemp.exe and set the Priority sky high to see if that makes any difference. I'm curious.
RejZoR: I mentioned that to W1zzard but I don't think he wants to share. ;)
I wouldn't share that code either. This issue has become less of a priority for me since I installed a Nvidia 9800GTX+. I'm happy with RealTemp as is.
RT 3.13 does the job :up:
Thanks for confirming that DGill. I'm happy to see that RealTemp is finally working 100% for you or maybe I should say 99.1%. :)
I think I'll add a darkzone=1 INI switch to the next release so everyone will finally be happy.
3.13 rocks :up:
http://www.fileden.com/files/2008/3/...alTempBeta.zip
A few minor bug fixes so that the RealTemp RivaTuner plug-in and RealTemp share the load timers better.
I've also switched to the latest WinRing0 driver. If there are any new bugs, I'll have something new to blame! :)
Well, I know you won't like this, but ...
Stuff like that used to bother me darkzone but not any more. You've got 3.07 that works great on your OS. I'll try to add that INI file option tonight to see if we can get 3.15 working for your combo as well. It will be interesting when you do a fresh install of Server 2008 this weekend. I'm looking forward to some more bug reports. :)
thanks for the hardwork & keeping us updated with the best temps monitoring program ;)
keep up the good work uncle! :up: :worship:
I just want to ask if there is a way to change the color of this text?
http://img19.imageshack.us/img19/8126/realtemp.png
thanks in advance :)
That's a bug in the old C++ compiler I'm using when the rounded modern looking buttons are being used.
I have a demo version of C++ 2008 which might include a fix for this bug and will let me change and control the color of those headings.
I'll put it on the short, things to do list to see what's possible. :)
I decided to switch to Visual Studio 2008 and found that all the easy ways outlined on the net simply don't work when you are using the modern XP/Vista style.
I did find a work around though that doesn't look too bad.
http://img15.imageshack.us/img15/2126/realtemp315.png
DJSUB: This is probably going to be a custom version for you. Since you're not using an Nvidia card would you like me to get rid of that white 1067A button in the top left corner? I think it will look better that way. I'll just put the 1067A in green with the rest of the data like the good old days.
I'll probably make one of each version. The heading colors will match whatever text color you choose. If someone needs this color customizable then I might throw an INI file text color option in there for you.
http://img16.imageshack.us/img16/4444/newmini.png
On second thought, I might just throw a color picker in there for the headings. :)
Every time I close RT 3.13 and 3.14 I get a windows error "Real Temp has stopped working" but 3.00 closes just fine. :shrug:
3.14 closes fine for me.
Hoss331: Are you using x64? One other user mentioned this issue so I'll have a look at it.
It's closing like a charm here. Vista64 SP1.
wow i like it uncle!
i can't wait for that version to come out :D
that's a great addition if you can match the same color scheme for the gpu.
that black & green color scheme is for my DFI Lanparty UT P45 T3RS
and my next target is black & red for my Foxconn Bloodrage :D
thanks in advance :)
keep up the good work! :up: :worship:
Me too! By default, I have no control over that choice of color when using XP / Vista style but I found a way to set those headings back to the previous style so I'm allowed to color the headings without having to send all of the buttons back to the ugly old style. In some situations, like above, you need a close eye to notice the difference but other times sending those headings back to the old style will look uglier so I'll include some switches and buttons somewhere in the Settings window for better user control of this. It reminds me of the green and black LanParty utility.
It's s.h.i.t like that that keeps me motivated. :)Quote:
keep up the good work! :up: :worship:
Hoss31: I decided to check out Windows 7 x64 and I have not had one issue with any version of RealTemp closing. I just downloaded 3.14 and opened and closed it 20 times and it was fine. I can think of one or two things that I've changed recently that "might" be causing a problem so I'll change that back to the RT3.00 way and see if that makes a difference for you. Both users to report this issue have been using Vista x64. Another head scratcher for me when code works 100% on one users version of Vista x64 and 0% on another users version. :confused:
I just got a new ssd the other day and the closing error only happens when ive booted it. Its using the same OS and is fully updated but only errors with 3.13 and .14. I can boot up from my original wd 640g and it has no problems when closing RT 3.13+. :confused:
I have windows 7 64 bit with intel SSD, no problem closing RT 3.14 on mine. Maybe something went wrong/different with install of your OS on the SSD.
So far so good with 3.13, thanks for the update!
im using vista x64 with UD3P-p45 and i get the same message as hoss331 when i close realtemp.it say realtemp has encounterd a problem and needs to close,(doo you want to report the problem to microsoft)
I'm just working on adding some control to the heading colors.
I found a place to squeeze in a new button. :)
http://img13.imageshack.us/img13/7752/rt315.png
The RealTemp encountered a problem is definitely a real problem so I'll have a good look at that.
I should have a new beta out for some testing within a day.
Nice work, uncle ;)
Keep up the good work Uncle!
http://www.fileden.com/files/2008/3/...lTempBeta2.zip
http://img11.imageshack.us/img11/6404/djsub.png
I wasn't sure whether to call this the Black Edition or the DJSUB Edition.
DJSUB it is. :)
If you don't like the ability to color your headings then in the Settings window click on Headings and when the color picker pops up just click on Cancel and then select Apply or OK and it will use the standard XP/Vista style for your headings.
The GPU button no longer appears for ATI owners.
This version is built using Visual Studio 2008 which uses the new and improved MFC90 library. I haven't yet decided if I'm going to permanently upgrade RealTemp to this version or maybe go back and add these new features to the previous version. It will depend on how many bugs I've fixed and / or created this time.
burebista tried it on Vista x64 and gave it a :up: and I tried it on Windows 7 x64 without any issues.
The WinRing0 x64 library changed recently so extract this download into a new folder and try running it from there when testing.
I included some code for darkzone's broken OS so if this causes any of your cores to go missing or if there are any other problems then let me know as soon as possible.