CPU cycles vs. total CPU time

On Windows, GetProcessTimes() and QueryProcessCycleTime() can be used to get totals for all threads of an app. I expected (apparently naively) to find a proportional relationship between the total number of cycles and the total processor time (user + kernel). When converted to the same units (seconds) and expressed at a percent of the app's running time, they're not even close; and the ratio between them varies greatly.

Right after an app starts, they're fairly close.

3.6353% CPU cycles
5.2000% CPU time
0.79    Ratio

But this ratio increases as an app remains idle (below, after 11 hours, mostly idle).

0.0474% CPU cycles
0.0039% CPU time
12.16   Ratio

Apparently, cycles are counted that don't contribute to user or kernel time. I'm curious about how it works. Please enlighten me.

Thanks.

Vince

The GetProcessTimes and the QueryProcessCycleTime values are calculated in different ways. GetProcesTimes/GetThreadTimes are updated in response to timer interrupts, while QueryProcessCycleTime values are based on the tracking of actual thread execution times. These different ways of measuring may cause vastly different timing results when both API results are used and compared. Especially since the GetThreadTimes includes only fully completed time-slot values for its thread counters (see http://blog.kalmbachnet.de/?postid=28), which usually results in incorrect timings.

Since GetProcessTimes will in general report less time than actually spent (due to not always completing its time-slice) it makes sense that its CPU time percentage will decrease over time compared to the cycle measurement percentage.