Thanks. Spot on! I had C1E enabled for some reason. Must have missed it when I switched to BIOS v1002 for this ASUS P6X58D-Premium. I also found that I didn't switch back to AHCI so I'd best be more careful next BIOS update. It's too easy for me to get a little sloppy since BIOS updates are so seldom made. I need to completely go through every single step of a new BIOS and concentrate on the OC last! Just as I would a new mobo. Which I'll be doing very soon, I hope. I have a new RE3 that I bought in March. I've been slowly accumulating the best parts for it since I bought it. The last few parts arrived Friday.
Thanks again for the help and reminding me to be a lot more careful.
Cheers!

Feature Request:
RealTemp would be complete for me if it could read HDD temp.
I'd really appreciate the display the hottest core feature. (6 cores, have mercy )

Issues: Using RealTempGT My 5970 is identified correctly and shows the correct temp but if I mouseover the task bar icon it says Nvidia GPU. ATi is checked in the settings. Using Realtemp (regular) mouseover simply says GPU Temp.

Also it says "crossfire support" does this mean I should be able to read more than one GPU temp? If so I cant . I have 2 5970s and would be more than happy to provide any help I can.

Story:
I love realtemp and even more now that it has built in GPU monitoring. I was devistated by the loss of my beloved MotherboardMonitor (MBM) and ATITool when I upgraded beyond their limits. I tried CoreTemp and RealTemp when I first built my i7 rig but went with CoreTemp at first simply due to it's ability to show the hottest core (I have a 980x six cores + gpu temp is alot of taskbar real estate). Then I realized RealTemp could read GPU temp so I switched back. I just display Core 1 as it's usually the hottest. Regardless RealTemp is my favorite temp monitoring software!

Request if not too difficult:
Lastly I have a server running an NCCH-DL motherboard. For a long time there was absolutely no way to use software to monitor it. Finally the latest bios and speedfan get along well enough to display NOTHING but CPU temps. It works ok but I'd much rather use realtemp. The Irwindale processors I'm running support "Thermal Monitor 2" As I'm sure you know RealTemp won't run on this older hardware. Would getting data from them be radically different than how you read the data from newer CPUs? I have no idea how software like this works.

RealTemp GT originally only supported Nvidia GPUs so when I released the update, I forgot to correct that minor bug.
The above version won't call your ATi GPU an Nvidia anymore.

When sitting at the desktop, the ATi driver by default shuts down unused GPUs to save power. When this happens, RealTemp does not wake your unused GPUs up to read their temperature because I didn't want to interfere with their power saving ability.

When you are 3D gaming with CrossFire enabled and using all your GPUs, RealTemp should be reading temperature data from both of your cards. During a game, ALT+TAB out to the desktop and click on the RealTemp GPU button on the main screen and open up the ATi Info window. In that screen when you click on the GPU 1 button at the bottom, does it cycle through all of your GPUs?

I had a pair of 5770 cards in when I was testing this out and in theory the method I'm using should work with your hardware but without a pair of 5970 cards to test on, all I can do is hope it works.

It's been a while but I think the way it was designed is that after a second GPU was used, its temperature data would remain available for viewing in the RealTemp ATi window. No new data would be gathered after you went back to the desktop and the GPU went back to sleep but the old data should be available. I think it took about 30 seconds for the GPU to go back to sleep after switching to 2D mode. If you are able to access the data from the other GPUs and suddenly it stops collecting new data, that's what is going on.

Give this a try and let me know what you find out. There used to be a registry hack to keep both or all of your GPUs active when sitting at the desktop in 2D mode but all that does is create heat, noise and waste energy.

With 6 cores, reporting the highest CPU temp in the system tray is a good idea. I'll put that on the things to do list. I probably won't be adding hard drive temperature monitoring anytime soon.

Aha! So that's what that GPU1 button does!!! For some reason I only tried to click on it using my C2D system which only has one GPU... It did nothing, and I shrugged it off. It does indeed work perfectly and displays all four high/low readings and, after running something 3d, actively reads all four until the 3 go back to sleep (lazy GPUs...). So everything works exactly as you described.

RealTemp 3.60.1, as adversed, now says "GPU Temp".

If you implement a highest temperature shown feature you may consider doing the same for any active GPU temps as well. It's not as big of an issue since if you're gaming you can't see it anyway. It would be cool to be able to glance down there if you alt+tab or are just exiting a game to see how everybody is doing though.

Thanks for letting me know that this feature works as intended. Without access to hardware to develop on, sometimes I have to wing it a little.

On the main window of RealTemp, the GPU button should be reporting the highest GPU temperature. It compares all active GPUs and reports the highest. After doing some gaming, cycle through GPU1, GPU2, GPU3, GPU4 and the main button should show the highest. The hottest GPU shows up in the system tray as well. Now I just have to start reporting the highest CPU core temperature in the system tray and maybe everyone will be happy. At least for a day or two.

Apologies if I've missed something but I've searched google and on the forum - does RealTemp publish data to shared memory or use any other method of making it's readings available? I was really hoping to find out if it did and what structure it used but I've not managed it.

I was playing with my cpu and found an interesting bug. I have an MSI P55-GD55 mobo. It has Direct OC base CLOCK buttons, so i can instantly increase or decrease my base clock frequency without rebooting. CPU-Z immidiately shows any changes, realtemp don't.

It's by design but it usually doesn't take 10 minutes for RealTemp to get a BCLK change figured out. After using SetFSB on my QX9650, it takes about 3 or 4 seconds to update the BCLK. If I had access to more new hardware I could probably make this better but I don't have any Core i stuff to test on.

Constantly calculating the BCLK wastes a lot of CPU cycles so that's the reason why I'm sure there is some hardware where RealTemp is sluggish to respond to a BCLK change. Usually when a CPU is loaded, RealTemp changes pretty quickly.

Here's an example of the cost of accurate MHz.

While CPU-Z is consuming 118 million CPU cycles, RealTemp is only consuming 1.9 million with both programs minimized.

RealTemp's main purpose is temperature monitoring and to be a very light weight app that can sit in your system tray without putting any load on your CPU. I admit, I sacrificed some instantaneous accuracy for users that like to adjust BCLK on the fly.

Can you try to do some more testing with a load like Prime95 running? Is it really taking 10 minutes to adjust? That seems like a long time.

The multiplier data, when lightly loaded, is not always going to be the same as what CPU-Z is showing. Is the problem the multiplier or the BCLK that is taking so long to update?

The problem you are having is likely related to a Windows 7 bug in the high performance timer when changing the BCLK.

I wrote a program called WinTimerTester a while ago to help detect this problem. There are two different timers within Windows. The high performance timer that is usually extremely accurate, can become completely inaccurate when you adjust the BCLK within Windows. On some motherboards there is a HPET (High Precision Event Timer) bios option that you can have a look for.

Can you try running WinTimerTester for a minute at your default BCLK, stop it and save a screen shot of it. If you hold down the ALT key while pushing the Print Screen button on your keyboard it will take a snap shot of just the high lighted program that you can paste into any Paint program and save.

After that test, increase your BCLK while in Windows and then run the same WinTimerTest again for about a minute and send me a screen shot of that.

There's obviously room for improvement in the RealTemp MHz algorithm when the BCLK changes while in Windows. Without hardware to test on, I'm not sure if I'll be able to make any progress on this but if you're willing to help then I'm willing to try a few things. I might have to come up with an option that will make RealTemp burn some more CPU cycles but it should be more accurate for users that frequently change the BCLK.

Not quite yet. I was waiting for some more feedback from 4natic. I'd like to try and get his RealTemp MHz reporting correctly if possible when he is adjusting the BCLK. Without having access to some hardware that I can recreate this problem on, I'll need 4natic or another user to help me with some testing.

Not quite yet. I was waiting for some more feedback from 4natic. I'd like to try and get his RealTemp MHz reporting correctly if possible when he is adjusting the BCLK. Without having access to some hardware that I can recreate this problem on, I'll need 4natic or another user to help me with some testing.

Thanks 4natic for posting that info. At least now it is easy to see that Windows 7 is the true source of this RealTemp bug. The Windows QueryPerformanceCounter function that RealTemp uses is designed to provide extremely accurate time measurement. To accurately measure time on a PC, you need this to be based on an accurate timer that increments at a fixed rate.

The problem in your computer is that W7 is basing this on the TSC (Time Stamp Counter) which is the MHz your CPU is running at. This value is usually very consistent but as soon as you use software and change the BCLK, this highly accurate timer becomes completely inaccurate.

On my desktop computer and many other computers, W7 basis the QueryPerformanceCounter function on a fixed counter that is not tied to the CPU speed so QPC will provide accurate time measurement even when overclocking. This counter is fixed at 14.31818 MHz whether I'm overclocking or not. On your computer, QPC is wrong as soon as you start overclocking. One of the early beta versions of W7 had this bug on my computer but it was fixed in the final release.

This is a bigger problem than most people realize. There is a lot of software that is depending on QPC to provide accurate timing data when it is not. This can produce inaccurate results in a lot of benchmarking software when overclocking. I'm pretty sure that Fraps does not correct for this bug so its FPS data is not accurate when overclocking. Games that are trying to calculate FPS using this QPC function can also get screwed up.

RealTemp tries to correct for this bug but as you found, there are times when it is a little sluggish in updating itself and locking on to the new MHz after a BCLK change.

The two timers in WinTimerTester should be running at the exact same rate. When they are not, that shows that W7 is basing QPC on a timer that does not increment at a fixed rate.

This issue has been around for a long time. Windows XP used to have an option you could add to your BOOT.ini file called /USEPMTIMER to force Windows to base QPC on a fixed timer but as far as I know, there is no option like this for Windows Vista or Windows 7. There should be. Maybe in one of their service packs Microsoft will get this fixed up. Here's some background info about this issue in XP.

Your BCLK has increased by that amount so WinTimerTester shows that the QPC timer now has an error of approximately the same amount.

Did you find any HPT Timer setting in your bios?

I'll try making a minor adjustment to RealTemp in the near future to see if I can reduce the sluggishness of how it detects BCLK adjustments and then I'll send something your way you can test to see if it helps any. I have a lot better understanding of this issue compared to when I first wrote the RealTemp MHz code so hopefully I can make an improvement without screwing anything up.

burebista: Do you remember the name of that benchmark program you found that clearly had this timing bug when overclocking?

Derek12: Unfortunately I don't have any AMD hardware or the time to support AMD. I think Core Temp fully supports AMD.

A Core i5-750 has a default multiplier of 20 and a default BCLK of 133.333 so when you boot up at this speed the above testing program might show 2666.666 MHz. That confirms that Windows is basing the QueryPerformanceFrequency funtion off of the time stamp counter (TSC) when it should be basing it off a fixed speed counter like my computer does so time measurement isn't affected when overclocking the bus speed or BCLK.