Real Temp - New temp program for Intel Core processors

[unclewebb]

This is the source of this bug. In your first example, when not overclocking in Windows, the performance counter is showing that it is 99.99% accurate and would likely be even closer to 100.0% accurate if you ran WinTimerTester for a longer period of time.

In the second example, changing the base clock speed has screwed up the accuracy of the performance timer in your computer. During an elapsed time of 90.9 actual seconds, the performance timer claims that only 89.1 seconds have elapsed. The more you over or under clock from the speed you boot up at, the bigger this error becomes. I built some code into RealTemp so it tries to correct for this windows bug but it obviously could use some improvement.

This bug is not just a RealTemp bug. Any software that needs to accurately measure time uses the QueryPerformanceCounter() function. This problem can affect the accuracy of FRAPS as well as other gaming benchmarks and games themselves that internally calculate FPS and adjust the speed of the game based on that. If you've ever overclocked a computer in Windows and couldn't measure any performance benefit from that change, this timer bug might be part of the problem.

104.99 MHz X 0.9812 = 103.02 MHz

The ratio these timers run at lets you figure out the actual base clock speed your CPU is running at. The boot speed times the amount of error in these timers gives you the actual MHz.

This is why CPU-Z wanders around +/- 0.5 MHz. It can not depend on the Windows high performance timer to accurately calculate MHz because of this bug so it has to rely on a less accurate timer. The actual base clock speed is rock solid in most computers and doesn't vary by +/- 0.001 MHz but it's hard to calculate this when you don't have a stopwatch you can depend on.

When I originally wrote RealTemp, I didn't know anything about this bug. Now that I understand it better, I'll see if I can come up with a better fix for this issue.

some_one: Thanks for that tip. Fixing Windows is the best fix of all. Less work for me. I have a computer I'm working on at the moment that I think has this timer issue so I'll play around with that and see if this issue can be fixed that way. Windows XP used to have the /USEPMTIMER option that you could add to your boot file to fix this but I think they got rid of that in Vista and W7 so it is interesting to see that there is a new way to fix this issue.

Here's the old XP way.

http://blogs.technet.com/b/perfguru/...-boot-ini.aspx

[boogeyman]

I guess it's possible, but only for Sandy and TBH we don't know yet if that register is Vcore or a sort of VID request.

I have it working in RT via AIDA64 and it looks accurate as compared to CPUz.

[Daddyjaxx]

Both Realtemp and Aida 64 still both freeze on me running Prime95 on my Asus board. Linx and OCCT and neither freezes. I'm wondering if it is because AISuite is running in the background. I have seen stupid warning messages that my motherboard is running at -60c.

I've looked in MSCONFIG and I see no way of it not auto starting with Windows. It's not in the startup folder and there is no setting to not start with Windows. I may just uninstall it.

[boogeyman]

Both Realtemp and Aida 64 still both freeze on me running Prime95 on my Asus board. Linx and OCCT and neither freezes. I'm wondering if it is because AISuite is running in the background. I have seen stupid warning messages that my motherboard is running at -60c.

I've looked in MSCONFIG and I see no way of it not auto starting with Windows. It's not in the startup folder and there is no setting to not start with Windows. I may just uninstall it.

I don't like AISuite II, still kinda buggy and sluggish to me. There are 3 services that run for Asus, try disabling those or better yet remove AISuite.

[W1zzard]

This is the source of this bug. In your first example, when not overclocking in Windows, the performance counter is showing that it is 99.99% accurate and would likely be even closer to 100.0% accurate if you ran WinTimerTester for a longer period of time.

In the second example, changing the base clock speed has screwed up the accuracy of the performance timer in your computer. During an elapsed time of 90.9 actual seconds, the performance timer claims that only 89.1 seconds have elapsed. The more you over or under clock from the speed you boot up at, the bigger this error becomes. I built some code into RealTemp so it tries to correct for this windows bug but it obviously could use some improvement.

This bug is not just a RealTemp bug. Any software that needs to accurately measure time uses the QueryPerformanceCounter() function. This problem can affect the accuracy of FRAPS as well as other gaming benchmarks and games themselves that internally calculate FPS and adjust the speed of the game based on that. If you've ever overclocked a computer in Windows and couldn't measure any performance benefit from that change, this timer bug might be part of the problem.

104.99 MHz X 0.9812 = 103.02 MHz

The ratio these timers run at lets you figure out the actual base clock speed your CPU is running at. The boot speed times the amount of error in these timers gives you the actual MHz.

This is why CPU-Z wanders around +/- 0.5 MHz. It can not depend on the Windows high performance timer to accurately calculate MHz because of this bug so it has to rely on a less accurate timer. The actual base clock speed is rock solid in most computers and doesn't vary by +/- 0.001 MHz but it's hard to calculate this when you don't have a stopwatch you can depend on.

When I originally wrote RealTemp, I didn't know anything about this bug. Now that I understand it better, I'll see if I can come up with a better fix for this issue.

some_one: Thanks for that tip. Fixing Windows is the best fix of all. Less work for me. I have a computer I'm working on at the moment that I think has this timer issue so I'll play around with that and see if this issue can be fixed that way. Windows XP used to have the /USEPMTIMER option that you could add to your boot file to fix this but I think they got rid of that in Vista and W7 so it is interesting to see that there is a new way to fix this issue.

Here's the old XP way.

http://blogs.technet.com/b/perfguru/...-boot-ini.aspx

vista and windows 7 should use hpet if available.

have you looked into calibrating QueryPerformanceCounter using gettickcount or maybe something like setwaitabletimer?

[unclewebb]

W1zzard: Thanks for the info. RealTemp does try to calibrate QueryPerformanceCounter with GetTickCount but I know there's room for improvement. I have access to a board this week that I think has this issue so maybe I can improve how RealTemp handles this problem.

Daddyjaxx: Check out AutoRuns. It lets you find every last hiding spot for applications that start with Windows and is a big improvement over msconfig.

http://technet.microsoft.com/en-us/s...rnals/bb963902

Without AIDA64 running, my second computer has been stable without a single lock up . I also haven't had any other reports of RealTemp problems so try completely removing AISuite and see what happens.

[zalbard]

Check out AutoRuns. It lets you find every last hiding spot for applications that start with Windows and is a big improvement over msconfig.

http://technet.microsoft.com/en-us/s...rnals/bb963902

Completely unrelated, but thanks for sharing! Looks like a great tool!

[unclewebb]

Mark Russinovich and Bryce Cogswell did such a great job with Autoruns that Microsoft came along and bought them out.
That's usually a good sign that you must be doing something right or else they knew too much.

It's a great tool when hunting down malware and other junk in one's start up sequence.

[some_one]

some_one: Thanks for that tip. Fixing Windows is the best fix of all. Less work for me. I have a computer I'm working on at the moment that I think has this timer issue so I'll play around with that and see if this issue can be fixed that way. Windows XP used to have the /USEPMTIMER option that you could add to your boot file to fix this but I think they got rid of that in Vista and W7 so it is interesting to see that there is a new way to fix this issue.[/url]

This was discussed quite some time ago. IIRC it was suggested to find something similar in the BCD to fix it and I assumed (wrongly it seems) you found out about adding useplatformclock to the BCD.

The big question of course is why did Microsoft not want to use HPET by default in W7. I'm not so sure it's a bug but rather that there might be some reason for doing it that way.

[Bullu$]

@Unclewebb

I thought it was just a little "bug", didn't know it also decrease performance like that. I was planning to reinstall windows because of the slower performance I somehow get.
It explains a lot.

HPET is enabled in the bios.

Will try to insert /USEPMTIMER in the boot.ini and see if that will solve the problem.
Does the windows timer also infect with msi afterburner or other oc-software related to gpu?

[burebista]

Here is my thread where Kevin enlighten me.
From my testings pure GPU based benchmarks were unaffected by SetFSB.

[unclewebb]

I thought it was just a little "bug", didn't know it also decrease performance like that.

The problem with this Windows based bug is that it's impossible to know what benchmark programs or games or whatever will start screwing up when you overclock using SetFSB or a similar tool. The Aliens vs Predator example that burebista posted clearly shows this.

http://www.hardwarecanucks.com/forum...ck-gaming.html

You wouldn't think a professional looking benchmark like that would have this bug. You also wouldn't think that Fraps has this bug too. Maybe its been fixed in the most recent version but probably not. To accurately measure FPS data, you need to use an accurate timer but you can't always depend on that in Windows.

When WinTimerTester shows the two clocks running at different speeds, that can be a problem for RealTemp but it can also be a problem for a wide variety of programs. The Microsoft QueryPerformanceCounter() function then becomes like a cheap wind up watch that can either be running too fast or too slow. I hope no one has been doing any SetFSB overclocking on the nuclear power plant they are managing.

This bug could also screw up video production type software that is trying to set the frame rate to a precise number based on timing data from that function.

[unclewebb]

Three cheers to some_one for coming up with the best solution for this problem.

Here's a program you can use to see if your computer has this timer issue.

WinTimerTester 1.1
http://www.mediafire.com/?xzo9n84d8lze9nb

I got my hands on an Asus board that has this problem when overclocking in Windows. The default base clock is 133.75 MHz. By using TurboV, I overclocked that up to 140.30 MHz.



You can see that by overclocking within Windows, this has screwed up the accuracy of the Windows QueryPerformanceCounter function by the same percent as I overclocked by.

140.30 / 133.750 = 1.0489

If you have this problem and you like overclocking within Windows by using SetFSB or a motherboard utility like TurboV; the best thing you can do is tell Windows to use a timer that runs at a fixed rate that doesn't have this issue.

To do that, open up a command window and type in:

bcdedit /set useplatformclock true

This tells Windows when it boots up next time to use a timer that runs at a fixed rate regardless if you're overclocking or not so it can be used for accurate timing.

Here are the results:



The QueryPerformanceCounter timer now runs at the correct speed when overclocking. You can see that QueryPerformanceFrequency is reporting a different speed which confirms that Windows is now using a different timer.

If you ever want to go back to the default Windows timer that has this timing bug then open up a command window and type in this.

bcdedit /deletevalue useplatformclock

I'll try to fix RealTemp someday so it better handles this problem but it makes more sense to fix the source of the problem which is Windows. Less work for me.

Here's some more background info which explains this bug further.

http://www-947.ibm.com/support/entry...d=MIGR-5084072

some_body says this fix is only for Windows 7 or Windows Server 2008 R2. Vista is not supported. My computer with Vista already uses the 14.31818 MHz timer by default so QueryPerformanceCounter works correctly, even when overclocking with SetFSB.

[Bullu$]

Tnx unclewebb, it working with above command line
W7 enterprise 64bit

[Daddyjaxx]

AI Suite was causing all of my issues with Realtemp AND Aida64 using Prime95. Both would always freeze during the 560000 test making my computer unresponsive except for Prime still running which was always no more than 35 minutes in the process. I uninstalled AI Suite and Realtemp an Prime have been playing nicely together for two hours now. No freezes...no lag...nothing. Going to try to reinstall Aida now to see if it freezes. I love Realtemp for running Linx or Prime, but I like the sidebar gadget and other monitoring tools of Aida.

Any chance on developing a gadget for Realtemp?

[unclewebb]

AI Suite was causing all of my issues...

Thanks for letting me know that RealTemp isn't causing the Windows freeze ups.

Any chance on developing a gadget for Realtemp?

I don't use the sidebar so that's why I've never gotten around to writing a RealTemp gadget. Maybe someday.

[randomizer]

Interesting CPU load numbers there. 100% nearly the whole time yet it get cooler? Is it just me, or does Sandy Bridge do the opposite of previous generations and converge at idle? Maybe it's just this CPU. I haven't been following this thread for a while, so maybe this has already been covered.

[unclewebb]

Hi randomizer, long time no see.

The RealTemp sensor test uses clock modulation throttling to vary the load on the CPU so you can see how the temperature sensors respond to slightly different CPU loads.

With Sandy Bridge, clock modulation throttling has changed as far as I know. It used to work by telling the CPU to skip cycles internally. I haven't personally tested this but I believe what happens now is the CPU multiplier decreases in steps. This is actually a better way to throttle a CPU so hats off to Intel for improving this. The only problem is it screws up the percent numbers in the RealTemp Sensor Test. Technically, the CPU is still running at 100% but it's 100% based on the reduced multiplier if that makes sense.

Most people know that the sensors Intel uses for thermal throttling and thermal shutdown control are not 100% accurate temperature monitoring devices. I guess the Sensor Test is still good enough to confirm that.

[CruNcher]

Hi unclewebb could you take a look @ your Rivatuner plugin http://forums.guru3d.com/showthread.php?t=285259&page=4 ?

[unclewebb]

Last time I talked to the programmer of Core Temp, he was too busy to get his program updated for Sandy Bridge so I can't recommend using it until it is updated.

What CPU-Z reports when a CPU is lightly loaded has been designed for consistent CPU-Z validation purposes so it might not be the best source of information if you need to know exactly what your CPU is doing internally. HWiNFO32 used to be similar to CPU-Z but with Sandy Bridge, CPU-Z has made some changes so I'm not sure how they compare now.

RealTemp, i7 Turbo, ThrottleStop and the RTCore.dll RealTemp RivaTuner plugin follow the multiplier reporting method outlined in the Intel November 2008 Turbo White Paper. When a CPU is lightly loaded and some of the cores and threads are using the various C States, the average multiplier tends to jump around quite a bit. When turbo boost is rapidly cycling on and off, the average multiplier can also increase and decrease rapidly. That's the data my software reports. It's not always pretty but by using high performance timers within the CPU, it's extremely efficient and accurate at reporting the multiplier transitions.

I like seeing exactly what the CPU multiplier is doing internally while other users prefer to look at a stable multiplier like CPU-Z reports.

Bios C State settings like C1E/C3/C6 and the Control Panel - Power Options - Minimum processor state setting both interact with each other and determine the average multiplier your CPU operates at. Play around with those and that might help you understand what software is telling it like it is.

Here's another program I wrote that lets you play around with some of these settings without having to reboot when testing.

ThrottleStop 2.99.6
http://www.mediafire.com/?26tu6cjmgu8ze9a

[CruNcher]

Last time I talked to the programmer of Core Temp, he was too busy to get his program updated for Sandy Bridge so I can't recommend using it until it is updated.

What CPU-Z reports when a CPU is lightly loaded has been designed for consistent CPU-Z validation purposes so it might not be the best source of information if you need to know exactly what your CPU is doing internally. HWiNFO32 used to be similar to CPU-Z but with Sandy Bridge, CPU-Z has made some changes so I'm not sure how they compare now.

RealTemp, i7 Turbo, ThrottleStop and the RTCore.dll RealTemp RivaTuner plugin follow the multiplier reporting method outlined in the Intel November 2008 Turbo White Paper. When a CPU is lightly loaded and some of the cores and threads are using the various C States, the average multiplier tends to jump around quite a bit. When turbo boost is rapidly cycling on and off, the average multiplier can also increase and decrease rapidly. That's the data my software reports. It's not always pretty but by using high performance timers within the CPU, it's extremely efficient and accurate at reporting the multiplier transitions.

I like seeing exactly what the CPU multiplier is doing internally while other users prefer to look at a stable multiplier like CPU-Z reports.

Bios C State settings like C1E/C3/C6 and the Control Panel - Power Options - Minimum processor state setting both interact with each other and determine the average multiplier your CPU operates at. Play around with those and that might help you understand what software is telling it like it is.

Here's another program I wrote that lets you play around with some of these settings without having to reboot when testing.

ThrottleStop 2.99.6
http://www.mediafire.com/?26tu6cjmgu8ze9a

Now i understand Aida64 and CPU-Z show only a approximation (striped down) of where the Multiplier is @ and CoreTemp and RealTemp show the real high resolution state (so almost realtime the state switch up/down)
I also prefer that exact way for measuring purposes

Yep i played around with Minimum Energy and High Performance Profiles and i was surprised when i looked @ my Watt meter seeing no visible consumption down like im used to from CNQ, i guess idle is already optimized to the last gate already and the real difference gets visible with Profiles and Sandy Bridge on Load (didn't test that yet) or my Watt meter standard consumer one is just not efficient (high res) enough seeing the Consumption change.

As i said on Guru3d it would be rocking if you might find the time implementing also the other Sensors like VID,Multiplier,BCLK state and Power Consumption anyways great tools great work thx

Wow ThrottleStop 2.99.6 is nice also i can force Multiplier first 3rd party App i see that can do that i suspected something like that Asus EPU is doing when you set it on Maximum Energy Save Profile, do you think it's possible to unlock locked Multiplier or @ least force the 1 Core turbo 34 Multiplier for all Cores on H67 ?

Igor Levicki once unlocked VT on Sony Vaio Laptops EFI Bios http://levicki.net/articles/tips/200...o_EFI_BIOS.php i guess he has the knowledge as Black Belt Intel Member to be able todo it, though i guess the Restriction system for it isn't inside the Main Bios itself but inside Intels Proprietary IME part wherever that is located maybe you can contact him and have a talk from Dev to Dev .

[unclewebb]

The Core i CPUs that are setup to use the C6 sleep state, will reduce the core voltage down to zero so power consumption of that core can also drop to zero. I've seen some screen shots where the CPU package can spend over 90% of the time in the C6 state. When this is working correctly, a lot of the other adjustments you can do to a CPU won't significantly change power consumption. It's usually hard to accurately measure a difference with a consumer grade power monitoring device like a Kill-a-Watt meter or similar.

Unfortunately Intel has made some changes to Sandy Bridge and I don't have any of the good documentation for insiders. Being able to change the multipliers higher like ThrottleStop could do on previous Extreme and K series CPUs might not be possible anymore. There are a lot of lock bits in these new CPUs to prevent 3rd party apps from having some fun unless you rewrite the bios.

[CruNcher]

Yep i see that with Throttlestop i get a maximum of 60% C6 state idling with both High Performance or Minimum Energy Profile (compared to my old Athlon 64 X2 K8 where i had a idle drop down from CNQ of about 10W) so it basically makes no difference anymore the difference though comes @ load, applications on the Core I Cpu run faster with High Performance Profile on Load (faster thread scheduling), so i would say on XP actually it doesn't matter anymore which Energy Profile you use the CPU will be very low power on both though on the High Performance Profile it will keep more Performance @ Load (dunno yet the Power Consumption differences for the Load state though)
The difference in speed drop down in a 4 Core scenerio @ Load are though small but (you can miss them with a unoptimized OS easily) they exist
Also i could successfully Overclock on my Asus P8H67-M Pro so far to 3.3 Ghz and i see a nice speed up (testing especially with Video Encoding) into the direction of the I5-2500 obviously my speedup from my Old platform @ roughly the same power consumption (idle improved by 30W alone) is a huge one 2x more efficient under load with roughly the same power consumption (@ before 2.5 Ghz)



With High Performance Profile it stays mostly from the start @ Multiplier 20x but is fast fluctuating up/down
Its really awesome to see Intels low Power Atom research inside their main Desktop CPU

[CruNcher]

@unclewebb

There seems to be a very heavy bug in rtcore.dll
if it's loaded i can't change any Sensor options the OK button in any Sensor Setup Dialog is greyed out

[unclewebb]

Can you be more specific and show me some screen shots and tell me exactly how I can recreate this bug?

I just fully loaded my CPU with Prime95 while RivaTuner was running and when I right clicked on any graph, I had no problem adjusting any of the parameters and saving them.

What are you using to load your CPU and what priority are you running it at?

When testing, make sure you are only using the RTCore.dll plugin and nothing else.