I have seen a very interesting problem while playing "Cricket 2007" game on Windows. The problem is probably caused by cpu frequency scaling and it gives an interesting perspective on how power management in operating systems and hardware can affect application writers.
My laptop runs at around 800MHz when it is on battery and at around 2.1GHz when it is connected to the mains. Lets say I boot the system running on batteries and connect it to the mains after it boots up fully. If I run Cricket 2007 game on this now, it runs way too fast. The game is almost unusable at this stage. The only way I have found to rectify this is to reboot the system while it is connected to the mains. Alternatively, if I boot up the system while it is connected to the mains and later switch to battery before starting the game, it plays too slowly, far slower than a typical slow-mo replay. It is not the problem with the battery, because if I boot the system on battery and continue to run the game while it is on battery, it plays correctly.
The problem is pretty interesting. I suspect it is because of cpu frequency scaling because I can't attribute it to anything else. However, whose fault is it? application's? operating system's? I have some thoughts, but I have no idea of Windows internals, so I can't be sure.
The application has no idea that the cpu frequency has changed before it is started. It must be doing some calibration for timing when it is started, by reading the frequency of the cpu from the OS. It is quite possible that the OS does not provide correct information to the application. Lets say the system was booted at 800MHz and the OS stores this value somewhere. Later the system could be running at 2.1GHz, but when the application queries, OS still says it is running at 800Hz. The application does it's calibration based on this number and it goes horribly wrong because the cpu is running much faster.
On second thought, it is not correct for the application to depend on cpu frequency being constant. This frequency could be varying all the time on modern hardware, so any application that depends on this value for it's timing calculation could go wrong. The same holds for any application that performs time calculations based on TSC. Depending on TSC is an even bigger mistake on SMP systems.
This is a very interesting observation mate ... need to ponder over it and dig around with Win Internals
ReplyDeleteI wonder, since you said Cricket 2007. Intel has had the speedstep technology since 2005, afaicr. So any application should have known that the trick of one time calibration to find out it's utilization, won't work anymore.
ReplyDeleteProbably you need to raise a bug against the application or the OS or both.