1
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.
pong
Posted 2017-11-12T20:09:47.103
Reputation: 193
i guess the disk queue length in the resoure monitor is around 0.2? – Harry – 2017-11-12T20:13:34.993
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 – 2017-11-12T20:18:21.707
@Harry Will watch that value next time. What does it mean in short? – pong – 2017-11-12T20:26:22.337
@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 – 2017-11-12T20:30:30.883
Imagine that you are in an apartment building where no one else lives. the building has a network of small diameter water pipes, and large diameter drain pipes, and the drains have greater capacity than any one fully-opened tap can fill. Because the building (the PC) was made for many apartments (applications), no one application can ever max the drain output, because the possible input is too narrow. Modern computer systems mix components of many different speeds and widths, so only one task in a million can make them all line up for max use of each component. – Frank Thomas – 2017-11-12T20:31:28.197
@Harry Ok, got it. Can't tell if this would explain it, but there are times during the update where disk io and network are zero and busiest cpu is at 30% nevertheless. – pong – 2017-11-12T20:37:06.940
1@FrankThomas I'm not sure if we're talking about the same thing :) To be clear, I didn't expect all resources being maxed out at the same time, but one at a time. Regarding your illustrative building analogy and applying it to the Windows Update scenario: there are times where a single resource maxes out (a core aka water pipe), the question is why this doesn't happen all the time with the tap (aka Windows Update) being fully open? Your comment made me think of a reason I would accept, though, will add it to the question. – pong – 2017-11-12T20:42:18.257
also remember, you are not reading steadily from the disk, decompressing, and then writing steadily. you are reading and caching some data (which involves async DMA), decompressing it back to ram, waiting for the running read to complete, and then writing a bit back to the originating device (via another async DMA call) waiting for the writing to complete, and reading some more. A disk can only do one thing at a time, and even if those tasks are small, they still take time, while faster components are already working on the next steps. – Frank Thomas – 2017-11-12T20:43:20.423
@FrankThomas I think we are roughly going into the same direction with this one, ty! – pong – 2017-11-12T20:57:37.820
1One 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 – 2017-11-12T21:04:28.213