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.
http://blogs.technet.com/b/perfguru...or-the-usepmtimer-switch-in-the-boot-ini.aspx
140.66 / 133.67 = 1.0523
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.