Cycles here refers to CPU cycles, at whatever rate the CPU is running at the time. Cycle timing is usually more accurate but there are issues on some systems.The behavior of many CPUs of adjusting the clock rate according to the workload makes this difficult.
Non cycle based usage is calculated from the CPU time consumed by the process during the update interval. The problem is that this timing is rather course (about 15 ms on most systems) so a process with short bursts of activity may not register any CPU time at all.
Process Hacker and similar utilities report CPU usage based on information provided by the OS and for a variety of reasons this is not always completely accurate. The behavior of the OS is designed to maximize performance, not facilitate accurate reporting.
Measured CPU time on Windows 7 and later is done using a fixed-length TSC clock, which allows a resolution of 333ns (1/3 of a ms.). The 15ms resolution was the default on Windows XP (for an unadjusted clock -- it could be set for higher resolution at the expense of extra cycles, but setting it for a 1ms resolution didn't take any noticeable CPU.
The behavior of the OS is designed to facilitate accounting and scheduling where greater than millisecond accuracy is needed to allow correct rounding to the nearest ms. This becomes especially important when you are renting out partial computer-access via virtual machines as customers will want to know they they aren't getting short-changed on time slices.
It would be very useful if PH could display number of cpu seconds used(*100)/real-time interval to give an absolute usage of how much of 1 core a program is taking. If it takes 2 cores, then it would show 200%, (2 cpu seconds * 100/1-real-time second).
With Intel's current CPU's having up to 18 cores, the MS-method of time keeping shows a single-threaded task that is cpu-bound (using 1 cpu all the time) only taking 5.6% cpu. I've had conversations with people who have looked at non-sleeping processes using .5-1% on a 10-core cpu, and not understanding that the process (a single threaded process) was really taking 5-10%. Another user looked at the MS-taskutil display where it truncates cpu usage -- and they told me the process used 0% with 1% spikes. Duh... They also didn't understand why the same task, showing an active paging rate of 3MB/s (up to about 30-35MB where it would stay steady) was using all of the CPU's cache (didn't understand that Core i7's and Xeons from a few years ago only had 8-12MB of L3 cache and that this had nothing to do with MS's disk cache).
MS' is measuring cpu usage in nanoseconds, though their programmable timers only allow resolution down to 1/3 of a millisecond, which is poor as far as computers go (linux can measure < 1microsecond). MS also gives their file times in multiples of 100-nanoseconds since 12:00 A.M. January 1, 1601 (UTC).
(https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
). They still don't give alot of detail where they get the cpu time figures or how they account for variable clocks & cores...