Why the differences?
Attachment 79806
This is on the Gigabyte system.
Printable View
Why the differences?
Attachment 79806
This is on the Gigabyte system.
WoZZeR999: Don't worry about the multis. They get taken care of separately. This testing program will provide me with some data that I need to help understand this problem better. It's making more sense already. Post a screen shot when you get a chance and you can include CPU-Z as well or just tell me the multis and processor you're using.
msgclb: The 14.318180 MHz number in the lower right is provided by a frequency generator chip. You can see that my board works completely differently. I've tried a couple of Dell laptops and they seem to use 3.579545 MHz which is exactly one quarter the speed of what your board uses.
http://img393.imageshack.us/img393/6...ester01ma0.png
If you use SetFSB you could try dropping your FSB to 300 MHz and post a screen shot of that. No need to overclock more. Just overclock a little less.
[QUOTE=msgclb;3039195]I'd like to know what motherboard Grandpa is using!
ASUS Maximus Formula 1201 bios
Q6700
4-2GB (8GB) Mushkin PC2 8500 @ 1105Mhz 5-5-5-12-2T-50
4-Seagate 7200.11, 500GB (2TB) 32MB cach, 0-Raid
2-MSI 3870X2
1300W CoolMax
Thermotake Kandalf
Liquid cooled
Grandpa: A screen shot like above is just what I need so I have a chance of getting this figured out. There's nothing wrong with your board. It just works differently than the one I'm using.
I actually didn't have SetFSB installed on this system but I do now.
Attachment 79834
Grandpa, thanks.
unclewebb, is this a motherboard, chipset, manufacturer or don't know?
Maybe it's the clock generator!
Here you go. I have changed my settings I was playing Crysis, I need a little more horse power when I am playing it so I crank her up a little so I can play on High settings.:D
You might want to check your e-mail I sent you a screen shot earlier.
Hope this helps. I use a Q6600 with 8x multi/C1E enabled. So cpu-z shows 6x since taking screen shots are taken at idle times. I included the standard 450, and SetFSB'd it down to 445 and 440. DFI P35-T2R.
Yahoo Mail was trying to help me out by throwing your e-mail into the spam folder but I found it. Thanks Grandpa. Your results make the problem pretty obvious, to me at least. Now I just need to find a solution that is compatible with the boards that RT is working properly on.
The column of numbers at the far right above the Go button represents the amount of time that the program asks for to count MHz. On my board and on msgclb's board, the actual time is almost exactly the same as the requested time. On your board, it is always about 0.014 to 0.015 seconds more so RT ends up counting more MHz than your computer is actually running at. Hope that makes sense.
The problem is that when overclocking with SetFSB, you get almost the same effect. I just need to create some formulas to figure out when the clock generator chip is being generous so I can correct for that or when the user has his hand on SetFSB. I think with this new info, it's doable!
WoZZeR999: Perfect! I'm knee deep in data now so there's no reason why I shouldn't be able to come up with a solution. Your results show what I already sort of knew. The inconsistencies in timing are consistent. The timing numbers when not over or underclocked are almost exactly the same as what happens on Grandpa's board. My goal isn't to make RT as good as CPU-Z. I won't be happy until I can make it better! ;) CPU-Z floats around more than it should after the decimal point.
@unclewebb - great job with 2.60! You planning to add the following:
-ability to select where on screen the gamer mode projects the temps and allow custom coloring?
-ability to monitor additional temps such as NB/chipset, PWM, CPU, HHD's etc. (have a look at what hwmonitor can do.
Really unneeded but would be cool: allow for conditional coloring of gamer mode and/or tray mode temps such that the user can define three different colors and temp ranges. For example:
20-45
46-56
57-67
Again, the key would be that users can define both the ranges and colors.
Keep up the great work!
It's weird. Yesterday, when I gave you the report of it getting the FSB correct, All of the numbers on the left were within .1mhz of each other.
When all the numbers in the left column are very close together, then RT will probably be correct. When the numbers in the left column gradually decrease towards the correct MHz, then I will need to check for that and do a correction. The clock generator chip might be good one time and not so good the next time. It's up to software to figure out what it is saying and to interpret it accordingly. No worries now. The next version of RT should work correctly for all motherboards.
On my board when the numbers line up in the left column, I find that when I use SetFSB, the number at the bottom of the second column stays the same. On your board when using SetFSB, the number at the bottom of the second column was actually the correct MHz based on the maximum multi for your chip. It's easy enough to read the multis and come up with the correct total MHz from this.
http://img65.imageshack.us/img65/9465/setfsbdownqo8.png
I went from FSB 333 MHz to 300 MHz which screws up the timings in the secs column. There's a reason why only CPU-Z gets this right. It gets confusing when using SetFSB. Hopefully RealTemp will become the second program I know of to get the MHz right.
Anyone else have problems getting 2.60 to remember the settings specified? For example, I customized the core temp colors/font and enabled gamer mode and saved the settings. After closing/reloading the app, none of the settings were saved. This a bug?
Thanks graysky, I'll have a look at that. I know Gamer mode doesn't get saved but that was by design. It's not quite ready for prime time and wasn't designed for 24/7 use. I would like to do Gamer mode properly by feeding RivaTuner the info if I can get that figured out. The rest of the options are supposed to get saved.
Edit: If you click on the Save button in the Settings window it should work. If you click on the Use button it will only use your present settings but won't save them. The close gadget at the top right will dump any changes you make. That is the way Windows apps are supposed to work. The close gadget is equivalent to hitting the Cancel button if there is a Cancel button available.
I'll have a look at a few more combos to see if I can repeat your problem. Your custom coloring idea is interesting.
@uw - cool. BTW, gamer mode flickers when playing games. Here is a quick video of what I'm talking about with GTA:SA. click here.
That's the problem with Gamer mode at the moment. I did a half ass job on this feature and it shows. It only took about a dozen lines of code so I didn't invest too heavily into development. For me, it was usable enough to see some temps during some games which is better than nothing.
If I do this properly with RivaTuner, there should be zero flicker since it will update on screen at the exact same rate as whatever game you're playing. I think that would be a worthwhile feature. As always, RealTemp is a work in progress.
@unclewebb - cool man, just wanted to let you know about it... wasn't meant as criticism. Also, looks like coolest just raised the bar with the public beta of CTGrapher.
RealTemp on my Asus Striker II Extream gives very strange readings...
40C on Core1 and 30C on Core2 ? @ E8500
How can it be possible?
Don't blame RealTemp for the sensors that Intel has chosen to use. These sensors were never designed for accurate reporting of idle temperatures and the 45nm sensors are even worse at this than the previous generation. You're lucky you don't have a Quad core because some of them look more like random number generators.
Read the RealTemp docs about Calibration and you might learn a little more about the problems and how RealTemp can be used to get some more realistic temperatures out of your sensors. No other software will let you get even close compared to what RealTemp can do for your processor so don't blow it off yet.
I'd start by running Prime small FFTs on both cores and see if the temps get a little better balanced. You either have bad sensors or possibly an IHS to core alignment / contact issue.
graysky: Competition has been good for RealTemp and CoreTemp. I've previously thought about adding graphing to RealTemp but so far it hasn't been too high of a priority.
Unclewebb,
Instead of re-inventing the wheel on the graphing & logging, why don't leave those graphic/chart/logging stuffs to the built-in Windows Performance Monitor and you just need to provide the counters to the perfmon. Just love a program that is lean & "mean".
Think of the possiblity on running the graph on CPU load with the cpu temp together in the chart or other system components as well.
Another suggestion, make it as double modes which can run as a normal program and also as "SERVICE" mode, that will be truly awesome. ;)
.
Thanks for the suggestions bing. I'm not familiar with the capabilities of Windows Performance Monitor but now I've got something new to check out.
I'm a lean and mean fan as well and that's my top priority at the moment. I downloaded some free tools from Sysinternals and have already found some room for significant improvements. I'm taking it easy this weekend. A much more efficient RealTemp should be ready by early next week for some testing.
Great new features in RT... ;)
uncle, concerning bing's suggestion regarding window performance monitor:
what about creating a plugin for rivatuner? i guess most people here are using rivatuner for tweaking and monitoring their graphic cards anyway. i use some standard plugins and everest to display cpu and memory utilization, all temperatures available via motherboard sensors and also fan speeds. its also possible to log this information to a file and display the graphs later. very handy during an overnight run of stability tools. thus rivatuner turned to my favorite tool for my monitoring tasks!
have not yet looked into plugin creation myself but from what i have read it should not be to complicated. may be its easier than integration into windows performance monitor.