Originally Posted by DireFog
To make one thing perfectly clear: /pmtimer is no magic bullet!
A little background: some time back, in the days when the Pentium processor was created, some schmuck at Intel decided that it would be a good thing to use a CPU register that was incremented with each clock cycle as a timing source. Game and multimedia applications were quick to use this (look up "RDTSC" if you want to know more).
For those who can't see why this is bad:
For one, this is by no means an easy source for "walltime". With CPUs running at different speeds, each CPU has a different number of "ticks" per unit of real time, so the TSC's speed has to be determined in relation to a physical clock.
In recent times, this has become even worse. Today's processors can change their core frequency prett ymuch arbitrarily, without warning. Intel Core (2) Duos can even run at different speeds per core. Enter the Windows process scheduler. That beast usually shuffles processes between CPUs at a high rate (explaining the nice ca. 50% load per core in the task manager you see on single-threaded applications, and some minor performance losses). So if an applications does two TSC reads to get a time difference, it has multiple sources of inaccuracy: CPU speed changing and CPUs running at different speeds. Scheduling between CPUs may even cause the second measurement to give a value "before" the first one. And yes, this is bad.
This, among other things, is why Microsoft introduced a call "QueryPerformanceCounter" in the API. It implements compensation logic for some effects. With the hotfix, it is also possible to use the aforementioned "/pmtimer" boot option to make QPC use the power management timer instead of the TSC.
Some games, e.g. early versions of Serious Sam 2 and all versions of Battlefield 2 use(d) RDTSC directly and thus screwed up because there was/is no proper compensation for that timer behaviour. AMD released a driver that makes the RDTSC option friendly. And now for the kicker: Intel has a synchronised per-chip TSC, so no compensation beyond the lock speed should be necessary. (In other news, most modern Intel-Chipsets should by now implement a so-called HPET, that is lightyears ahead of any other timer found on PC hardware. If you care, you might want to look for a way to use that one instead of the PM timer.)
Using that option does in no way enable some previously unused processing power, nor should it have any objective influence on the behaviour of Windows itself. All it does is make a single API call use a different time source.
