Task Manager's CPU meter is an obituary for the recent past, says the engineer who built it

Spoiler: There's no magic value.

Just a timer, some kernel calls, and too much coffee
Windows has always had a built-in portal to the very recent past: Task Manager's CPU usage meter.

"The CPU number in Task Manager is a moving little obituary for the immediate past," explained former Microsoft engineer Dave Plummer, "Not what happened at the moment that your eyeballs landed on the row."
'Windows sucks,' former Microsoft engineer says, explains how to fix it
Plummer wrote the original version of Task Manager, back when it was a lean, mean, process-killing machine rather than the considerably chubbier and cuddlier tool of today.

He has since led viewers through a tour of the source code , admitting along the way that he left his telephone number in the comments while chasing a strange bug in how CPU numbers were being reported.

That bug is the subject of his latest explanation.

So how did Task Manager report the CPU percentage?

The answer is complicated.

Windows had no magical CPU usage value waiting to be read.

Instead, Plummer's Task Manager was timer-driven.

Every time the timer fired, the code asked the kernel for cumulative execution times and compared them to the previous sample.

"For an individual process, the math essentially is the cumulative current CPU time minus the previous cumulative CPU time.

And that gives you how much CPU has been consumed by that process during the interval between the samples," he said.

"The per-process percentage is just that process's delta divided by the total delta."
"Now," the veteran engineer continued, "if that looks like the sort of thing you write when you've been locked in an office too long with a copy of Petzold and a lot of coffee, that's because it basically is."
"Petzold" refers to the books by Charles Petzold , which were an indispensable companion to Windows programmers in the 1990s, well into the 2000s and beyond.

Many long-serving engineers are likely still to have a well-thumbed copy or two on their shelves.

Elegant as the solution was, it had wrinkles.

Occasional quirks in the Windows kernel's reporting could make percentages fail to add up to 100, prompting a festooning of asserts in the code - and a request to contact Plummer directly if CPU usage ever exceeded that figure.

And then there is the problem of modern hardware.

Plummer said: "Back in the day, the scheduler's time accounting and the processor's actual throughput were much more tightly coupled because the CPU clocks were comparatively static.

On modern CPUs, though, the hardware is constantly changing gears.

"A mostly idle core may be downclocked, parked, or dropped into a state of sleep, sipping power through a cocktail straw, and then the instant that real work shows back up, it can jump up to a much higher frequency or even turbo past its nominal clock."
As Task Manager's accounting was fundamentally time-based, the work accomplished in any given interval varied wildly depending on what frequency the silicon was running at.

"The meter isn't wrong, but it's measuring sort of occupancy rather than productivity." It was built for a simpler era, before CPU frequency scaling and throttling became the norm.

"When the numbers [today] feel a little slippery, it's not because the tool is broken so much as the hardware stops being simple enough for a single percentage to tell you the whole story."
Plummer told The Register : "My main impetus was to account for every cycle, making sure each was properly attributed to the right 'cost center' and then determining how much actual work occurred in that time window.

That seems pretty accurate, and I guess more important, 'felt' right to me in term of what the machine was doing."
He was unable to comment on how the modern iteration of Task Manager performed the trick, telling us, "I know how I would have done it but hate to assume!" ®