|
I'd love to know how they come up with the estimated times to restart your PC for a Windows update. Do they just see how long it takes on the top-of-the-range development machine with a nuclear powered CPU and liquid nitrogen cooling and hard code that time, or is there some "cleverness" that theoretically looks at the actual PC concerned and makes an estimate?
Today's update was estimated at 3 minutes. Actual time to get back to a "normal-looking" screen was 16 minutes. It was 22 mins before CPU and disc usage dropped enough to make it usable.
Does anyone else receive more realistic estimates?
|
|
|
|
|
I've got 5 minute estimate - and I have one of those top-of-the-line computers you mentioned...
(Not actually let it do the update yet)
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
|
|
|
|
|
I selected to restart and then went to make a cup of tea. When I came back it was ready for me to log in again. It actually took less time than usual to log in and be useful again. Less than 5 minutes all told.
My PC is reasonably speedy but it's not nuclear powered or liquid nitrogen cooled.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Rich Leyshon wrote: I'd love to know how they come up with the estimated times to restart your PC for a Windows update
It's inversely proportional to your necessity of having a working machine.
So, if you are just turning on your computer for grins then it will only take milliseconds.
However, if you have an imminent Teams meeting with all 3 of your supervisors and you've just woken up for the day and your machine must be on, then it will take days. 
Yes, this is based upon my own experience. 
|
|
|
|
|
Now, there's the correct answer!
Though I've found it's usually then followed by a Zoom update, that is pretty quick but trashes settings and screen layouts so you can spend the first minutes of the meeting fumbling to get those reset; and that's always a meeting where someone has to ask you a question in the first 10 seconds!
|
|
|
|
|
My update was bit off - like 12 minutes instead of 5...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
|
|
|
|
|
I always try to schedule it for overnight so I don't have to think about. Until I come back to the machine and ask why the heck none of my applications are open.
Hogan
|
|
|
|
|
I agree with this. I try to process any updates as soon as possible so that they don't have the chance to interrupt me later on.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Same here.
I had a coworker (since retired) who would put off updates for days. To complicate matters, our IT dept. had an application on our machines that would display a window reminding you to reboot that had the "stay on top" enabled. It could be moved out of the way temporarily, but it would move itself back center screen once an hour. He would calmly move it back, every hour  .
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: He would calmly move it back, every hour  .
After having some problems with HDD encryption (Based on Hardware) after adding a second ETH-Card and all the fight I had with the corporate HelpDesk... I do exactly the same with the "you need to encrypt your D: - Accept - Not Now". Lucky me it only appears 3 times per day.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: "you need to encrypt your D: - Accept - Not Now"
We have that with McAfee Endpoint Encryption. I got so tired of dismissing the dialog that I wrote a little app to watch for the popup and to click the button that dismissed it.
Software Zen: delete this;
|
|
|
|
|
Content for a small tip?
No time to think it out myself right now 
GIMME CODEZZZZZ, PLZZZ, IT'S URGENTZZZZ
My luck is, it happens only in the PC (laptop has password), so it only bothers me, when I need to RDP in the PC for accessing the isolated intranet. For the rest I use the laptop.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I access my actual work PC using a laptop via RDP. The work PC is in the server room and ever since it moved there, if refuses to restart automatically and always requires that I call the service desk so someone can go in and power cycle it. Of course, if a monitor, keyboard and mouse are attached it's fine and started from power on is OK. Just warm reboots...
So I defer updates until I'm sure there's someone available to push the button!
|
|
|
|
|
snorkie wrote: Until I come back to the machine and ask why the heck none of my applications are open Windows is asking if it's OK to close Notepad
FTFY
|
|
|
|
|
Oh not me. I sit patiently watching whatever messages or counters are on the screen and listen for any unnatural clicks or whirring. Not so satisfying now that I’ve switched to SSDs. But habits are deep.
And, I ride a Harley, so listening for odd noises is a very ingrained habit. 
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Rich Leyshon wrote: Does anyone else receive more realistic estimates?
MS's inability to ever come up with accurate figures has been exposed since Windows Explorer started showing file operation time estimates back in Windows 95.
Obligatory XKCD comes to mind.
|
|
|
|
|
Conversely, I would argue this is a hard problem to solve. Thinking about my machine vs others and what is installed and running. I'm glad they take a guess to give me a clue what to expect. I'll take a moving progress with an inaccurate estimate over nothing.
Hogan
|
|
|
|
|
snorkie wrote: I would argue this is a hard problem to solve
Not solvable at all in a realistic sense.
The update time depends on the hardware and software on the box. Perhaps even what it is doing right then.
So potentially at least about 200 million different combinations (quick google for that number of windows 10 boxes.)
snorkie wrote: I'll take a moving progress with an inaccurate estimate over nothing.
A very long time ago I had to do several UI progress bars. Very hard to make it progress smoothly.
I no longer do UI code but I do need to provide progressive progress data. But still very difficult. I do not attempt to make it smooth rather I just try to make it progress.
To do a progress bar with percentages one must have a final count. I was attempting to do this for a recent progress collection and realized that to do that correctly I would have needed to do almost the entire work load to arrive at an accurate figure. And this is something that might (and does) take hours to complete. So doubling that amount of time did not seem like an effective solution. Not to mention the complexity and that there were failure paths as well.
|
|
|
|
|
jschell wrote: The update time depends on the hardware and software on the box.
So base it on the hardware and software on the box! You know what is to be done - how many files opened and closed, how many gigabytes to transfer over which channels. How much processing to be done. If the job comes with estimates from a model machine for each work component, and entries in the registry tells that 'Experience shows that file open on this machine takes 1.4x compared to the model machine, file transfer to disk D: goes at 3x the model machine speed, CPU bound tasks typically takes 70% as long' - then you can multiply actual measurements from the model machine by the local factors and sum it to a total. The finer breakdown of factors, the closer you will get to a correct estimate. It won't be completely off.
For a Windows update, the work to be done may not be known until you see which components of the update are relevant for this specific PC, but that you sort out as one of the first tasks. That will tell you how many file open/close, how many gigabytes of file data to transfer from/to which disks, how many seconds CPU each selected tasks requires on the model machine. Then you multiply and add. If the actual times turn out to be off the estimate, you adjust the multiplication factors stored in the registry for the next update, to make a more correct estimate at that time.
As long as hardware stays the same, the scaling factors from a model machine, when broken down to a reasonable level such as file open/close, average disk transfer speed, CPU bound processing, ..., will not be terribly different from one Windows update to the other.
|
|
|
|
|
snorkie wrote: Conversely, I would argue this is a hard problem to solve.
To make an exact estimate is impossible, especially when the machine is available for other use in parallel with e.g. a file copy operation.
If you have received a time estimate, and then start an operation that hogs all system resources for half an hour, you know that the estimate will be wrong. The problem is that if you do not start anything, the estimate still jumps up and down by a factor of 5, maybe 10, maybe 30. That is what makes little sense!
For the initial estimate, the number of files to be opened for read and for write is known, and on which devices. The amount of data in each file is known. The PC should know from earlier experience how much time a file open typically takes on the various devices. It should know from earlier experience the typical transfer speed from the source device, and to the destination device, and go for the lower in the estimate calculations. Also, the estimator should pay some attention to the size of disk buffers: Typically, transfer speeds are high until a read cache is empty, or a write cache is full; after that it drops. This can be learned from experience. So the initial estimate should be close to the typical time from earlier experience in the same installation.
The problem seems to be that if the measured transfer speed deviates from the typical speed for half a second, e.g. because some application flushed a thousand modified disk pages, then all earlier estimates seems to be thrown away completely. The estimate is not slightly adjusted, but entirely recalculated based on that half second. If the expected total time is 500 seconds and for 0.5 seconds the measured transfer speed is almost down to zero, the next estimate should be based on a transfer speed 999/1000 of the "typical" one. Similar for file open and other operations.
After completing one such operation, the actual average time for file open/close and transfer speed should be used to adjust - not replace - the "typical" times for that device stored in the registry, e.g. like new typical = old*0.9 + last*0.1. So if you more or less always run other applications in parallel with the copy, the typical value may slowly crawl upwards to a "correct" value for your machine. If the initial typical value was based on your old SATA flash disk, recently replaced with a much faster M.2 disk, the typical timing values where that disk is involved may slowly crawl down to a lower, fairly stable value.
For the Windows update, there is also a processing element. MS should know that on this model PC, this processing step takes x seconds - but on one specific PC, in all previous updates, experience shows that the real time used for processing steps has on the average taken twice as long as on the model PC. So in the estimates, we assume that the step will take 2x seconds.
For both file copy and e.g. updates, there often seems to be some sort of final "cleanup" actions, much more than just closing files. (I hate it when the progress bar sits at "99% complete" for as long as the completed 99%!) Typical cleanup times after various classes of operations may be measured as well, stored in the registry and used as expected values in future operations of the same class.
If you base all such estimates on earlier experiences from the very same machine, there is no way that they could be off by a factor of 5, or 30. Or that they would jump wildly up and down. If you have updated your hardware, or if you put a heavy load (or remove a heavy load that was there earlier), you will see estimates that are somewhat off, for a while. But no crazy jumping up and down.
I refuse to believe that Windows base its estimates on earlier experience on the same PC. I refuse to believe that they let a brief, temporary deviation from typical performance have an effect on the estimate proportional to the duration of deviating measurement. If they did, there is no possible explanation why the estimates are bouncing wildly and sometimes off by a huge factor with no meaningful explanation.
MS apparently concluded: Making an exact estimate is so hard that we give up. We won't even try to make any reasonably close estimate.
|
|
|
|
|
The estimates for me are reasonably close, although they don't seem to include the shutdown and reboot time. The estimate only seems to cover the amount of time required to actually perform the update. Admittedly my setup is pretty simple, as I don't have a lot of third-party stuff installed that runs all of the time.
Some of those things (anti-virus especially) seem to trigger off of Windows Updates and do their own "do I need to update?" activity, which bogs the machine down.
Software Zen: delete this;
|
|
|
|
|
The point is to keep the user "entertained" (so they don't reboot) ... not accuracy.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Sure, the estimates are realistic. They are based on the percent of completion that is on your screen.
The percent of completion is based on the following:
1. The current moon phase
2. How close your dog is to you
3. The inverse of the day of the week number, i.e. they take longer on Mondays
4. As @raddevus saidQuote: It's inversely proportional to your necessity of having a working machine.
5. How full your coffee cup is; also an inverse relation
The formula has been very consistent for the past 25 years 
|
|
|
|
|
MikeCO10 wrote: 5. How full your coffee cup is; also an inverse relation
If you invert the cup, it will most certainly be empty.
|
|
|
|
|
I don't bother looking at the estimate any more (it's nice to be retired!!). I'll just start the update for the Windows VM and then switch back over to the Linux side of my system and continue browsing or whatever.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
