When watching Windows Update doing its work with Task Manager's performance tab and Resource Monitor open, the update process usually - i.e. ~99% of the time - doesn't max out any of the available resources. By far.

Some general figures observed:

  • Windows 10 Fall Creators Update 1709 took about 1.5 hours in total - a clean install is less than 5 minutes, but that's another question
  • cpu cores almost idle most of the time with a single core maxing out once in a while (even when it does, it usually won't run at maximum clock rate)
  • ram usage is at about 5% all the time, didn't expect that to max out
  • disk activity averages at about 10% with 100% almost never reached, used disk bandwidth far away from specs at about 10 MB/s
  • network connection maxes out if used (small amount of time)

As I understand it, there should always be a bottleneck limiting other resources; one of those resources should always be at 100% blocking further progress. But in case of Windows Update, a standard scenario snapshot looks like this:

  • busiest cpu core at 30%
  • ram at 5%
  • disk at 10% activity with combined read/write bandwidth of 10 MB/s
  • network at 0%

There simply is no bottleneck in Windows Update (maybe by design for marketing purposes) most of the time. Or at least it's not visible to me.

This leaves me asking what the computer is doing instead. Is this intended to not put too much load onto the system to prevent overheating or to allow for parallel usage/responsiveness at any time? Is it a bug or shortcoming regarding Task Manager or Resource Monitor? Is there any way to force Windows Update to use every resource possible?

Interprocess Locking/Concurrency issues as a reason?

Frank Thomas' "drains and water pipes" analogy made me think of a possible reason: interprocess locking. Since there are usually multiple cores in action, maybe they are waiting for each other. Or they are blocking resources any other thread or process needs. Likely or not? Will observe cores' orchestration next time. Better yet: apply an update inside a single core (virtual) machine and see if the theory holds true.

  • i guess the disk queue length in the resoure monitor is around 0.2? – Harry Nov 12 '17 at 20:13
  • No, there isn't. It's probably waiting for data from Microsoft servers. You might speed up the update by first downloading its full version and running it locally, but when all is totaled up you wouldn't be saving much time. – harrymc Nov 12 '17 at 20:18
  • @Harry Will watch that value next time. What does it mean in short? – pong Nov 12 '17 at 20:26
  • @harrymc Even if it's waiting for server data (which the network monitor didn't suggest), why would the cpu work at e. g. 35% in the meantime - b/c it knows how long the server roundtrip will take? :) Next time, I will do an offline update, though, and see if it makes any difference. – pong Nov 12 '17 at 20:30
  • 1
    One final note, your CPU is always running at 100% when it has running to do. it may mask off clock ticks to reduce the resultant frequency, but when it runs, it as a matter of physics, runs at 100%. the thing that may be confusing is time-slicing. when taskman shows 30%, what it really means is that it worked for 1/3 of the second in question. a single-threaded task that relies on IO can never max the cpu time because of the IO requests. it requires multithreaded applications in order to actually saturate the core, filling in the gaps while data is loaded. – Frank Thomas Nov 12 '17 at 21:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.