It is by very high resolution 'granularity of measurement' it can be noticed.
In a CPU there is no 50% load, it is either at 100% or it isn't for a given clock cycle. Technically there is now, because of power management, etc, but the software can't reall 'see' that happening in real-time. (and I really mean real-time here, not process priority levels
). Then you've got to add pipeline depth (number of stages) and width (number of issues) to it, and 'average' what is going on over all of them.... etc, etc
As the smallest unit of measurement the Task Manager is going to report is a timeslice (apx 20 ms, can be variable length though) it will just see how many clock cycles it was 'at load' for in a given timeslive. Then the graph spits it out as a percentage, of load per timeslice over 3-5 second period.
That 3-5 sec sampling doesn't help either.
If you could sample it 1 billion times a second, (A lot of data in a graph that you couldn't animate at that speed, and you'd need 1 GB of memory to store the data
), you'd be able to notice the square wave if you 'zoomed' in enough on the data.
It is sort of like zooming in on a WAV file until you can see only 1024 samples (assuming 1024 values visible within window on screen, which at 1152 and above is possible),... at 96 Khz the whole screen width is only going to be 93.75 ms of audio. Some audio software can do this, but audio waves are analog in nature.
Unrelated Tip: When splicing audio waves to join to others, always do it where the wave intersects zero, for each splice, then jon them. This stops pops/clicking in your audio. 8) - That is an example of what high resolution 'zooming' can do for wave forms. But for what is a square wave it only partially applies. Hopefully my point is clear though.