XPost: alt.comp.os.windows-11   
   From: nospam@needed.invalid   
      
   On Sat, 1/24/2026 6:41 PM, CrudeSausage wrote:   
   > On 24 Jan 2026 20:22:46 GMT, Frank Slootweg wrote:   
   >   
   >> CrudeSausage  wrote:   
   >>> On 24 Jan 2026 16:26:01 GMT, Frank Slootweg wrote:   
   >>>   
   >>>> CrudeSausage  wrote:   
   >>>>> On Fri, 23 Jan 2026 23:52:39 -0500, Paul wrote:   
   >>>> [Audio transcript deleted.]   
   >>>>   
   >>>>> You're going to tell me that you've never had an update take hours   
   >>>>> to complete?   
   >>>>   
   >>>>   Indeed, I never had that. We're talking Windows 11 here, which   
   >>>>   mostly   
   >>>> uses modern hardware (because of TPM and stuff) and probably SSDs.   
   >>>   
   >>> I've been using SSDs since 2009 and NVMes since 2015 and I've   
   >>> constantly faced that issue, even on hardware that was maintained   
   >>> regularly. Why do you insist on lying?   
   >>   
   >>   "lying"!? Bye, bye!   
   >>   
   >> [...]   
   >   
   > I assure you that I'll be spending my night in a corner, crying my eyes out.   
      
   We can only go by what we see here.   
      
   There are best practices to follow, and if people don't   
   follow them, they "get a surprise".   
      
   Around 2015-2016, I started what I thought would be a one week   
   long compute run (Image Composite Editor ~70 images). Four hours   
   into the run, a notification popped up indicating I must restart   
   the computer within some number of hours (which happened to not be   
   a week). I had to stop what I was doing, lose four hours work,   
   and start all over again. But there are things I can do today,   
   to prevent that from happening. Just the setting in Windows Update,   
   to delay updates, is enough.   
      
   There are things you can do, to make WU worse.   
      
   1) Switch from your SSD to HDD (Test Machine uses HDD for Win11...   
      it's what I've got for the purpose of using it, can't afford more SSDs) .   
   2) Download the 4GB version of a Cumulative Update, instead of using   
      the much smaller version that comes in through Windows Update.   
      It takes time for the software to whittle away at the 4GB thing   
      (a line at a time), until the bits that remain are determined as   
      being suited to your custom installation and its current operating state.   
      Just the order, or the timing of the installation of certain things,   
      affect what happens on a Cumulative much later.   
      
   While a WU is being installed, these may offer a slight speed advantage.   
      
   1) services.msc   Switch off SysMain (aka SuperFetch) as it is "mostly   
   pointless".   
   2) Bring up the Security interface, switch off Real Time protection.   
   3) Open Task Manager, kill the SearchIndexer.exe process   
      
   Those are examples of activities that reduce the I/O level enough, that   
   Windows Update gets some bandwidth. When Windows Update adds 200,000 files   
   to the C: drive, this makes the SearchIndexer.exe go crazy with work.   
      
   If your processor has extra L3 cache, an update can install faster.   
   The reason we know this, is a 5GHz processor runs much much faster   
   than a 3.4GHz processor, and via clock rate alone, it's not apparent   
   where the gain comes from. We know that a piece of code written   
   in WinXP era, runs and sucks the life out of WU, and it is compute   
   bound. It would be my guess, that a little extra L3 on the processor   
   in question, is helping. Most of the stuff that Microsoft does,   
   is single-threaded, and the WU supersedence calculation is no   
   exception.   
      
   There is a theory that doing a "Rebase" on the OS, will speed   
   up future WU activity. But it appears that the argument is   
   likely neutered, and doesn't do anything. For example, if a new   
   W11 DVD was issued, and it was "ahead" of the base release   
   (26100 or 26200), maybe that would be of a slight advantage   
   to you (makes any security update run slightly faster).   
      
   The 26H1 listed here, will only install on certain hardware   
   and it's not likely for X86. 26H2 is likely to be more general.   
      
      https://en.wikipedia.org/wiki/Windows_11_version_history   
      
   On the Big Machine, I can have updates that take 2-5 minutes.   
   Not the sloggingly slow show on the Test Machine. And it is not   
   like the extra cores make a difference. The cache on the Big Machine   
   is not all that good, the incoming X3D would be better (two   
   cache dies that sit on top of two CPU dies for a total of three cache   
   segments).   
      
   I've only seen Microsoft software rail the entire computer, just once.   
   Windows Defender disassembled a 7ZIP with a libarchive with   
   multithreaded decompression of a large .7z . I have not seen   
   a repeat of this activity, and I cannot tell you whether   
   that was removed from the Windows version of libarchive or not.   
   Normally, libarchive does not exhibit such a feature (which is   
   why I use an installed copy of Igor Pavlov 7ZIP instead to   
   unpack such files). Most of the time, an 8C 16T processor,   
   the OS might use 3 cores worth. It's not exactly in a rush.   
   But the OS can manage to busy-out a HDD without too much trouble   
   (making it seek all over the place reading 2KB files). Even if   
   they used their own System Read cache, we could make WU that   
   ran fast on a HDD. But they won't do that, and they Read Uncached   
   for almost everything they do. The System Read cache is virtually   
   worthless.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)