CPU Frequency Program

[dedndave]

of course, we can get "a" value from a number of places
but, to know the actual current value, it needs to be measured
i have never tried overclocking my cpu (it's a prescott - not a good cpu for that)
but, that might be one example where measurement is nice
another example is, as with Hutch's new machine, it throttles the clock according to core tempurature
the values stored in the registry or other places are not going to reflect that
if you just want a rough idea of maximum operating frequency, QueryPerformanceFrequency seems like a good source
that value seems to be calculated or estimated at boot-time, and remains constant until the next boot
at any rate (pun), i wanted to see if it could be accurately measured without ring 0 access

EDIT
this is all part of my "learn win-32" process - lol
i wanted to become as comfortable with 32-bit console mode apps as i am with 16-bit dos apps
i have learned the "new" x86 pentium instructions and changes in the fpu (compared with 8087 - lol)
i have also learned a bit about the pe format, obj's, res's, etc
next step is to learn my way around mmx and sse instructions
then, i will be ready to attack gui programming, starting with simple "look and feel" type stuff
after that, i will go whatever direction the apps take me - graphics, ntfs, ring 0, other hardware, etc

[MichaelW]

if you just want a rough idea of maximum operating frequency, QueryPerformanceFrequency seems like a good source

Per the PSDK:

If a high-resolution performance counter exists on the system, you can use the QueryPerformanceFrequency function to express the frequency, in counts per second. The value of the count is processor dependent. On some processors, for example, the count might be the cycle rate of the processor clock.

I can't recall ever testing a system that did not support a high-resolution performance counter, or one where the frequency was not very close to 1193182 (Windows 9x) or 3579546 (Windows 2000/XP).

[dedndave]

mine returns 3,000,002,000 - very close to 3 GHz
well, it did the other day, when i was playing with it - lol

[Rockoon]

QPF() has multiple potential timing sources. You cannot rely on it *ever* being the CPU frequency on arbitrary systems.

On multicore AMD's running XP SP1, the QPF() source was indeed the cpu cycle count. But somewhere along the way between then and XP SP3 and AMD's "dual core optimizer" (which is actualy a windows patch) the source of QPF() changed, configured with the 'USEPMTIMER' switch in boot.ini or whatever.

The problem with the CPU tick count (RDTSC) being used is that if your process migrates cpu's (or even cores in the case of AMD's), the tick count can appear to move backwards since the cpu's tick counters are not in synch. This had caused endless problems for users of older games on multicore systems, because programmers normally assume that time cannot go backwards.. that the calculation (now - then) is always a positive number.

See http://www.google.com/search?hl=en&q=%2Fusepmtimer&btnG=Search&aq=0&oq=&aqi=g10 for a little bit about the USEPMTIMER switch.