Why can't computers boot instantly? (2013)
superuser.com
superuser.com
The argument that computers need to go from a useless state S0 to a useful state S1 and that takes a long time is just bullshit. The question is, how close can you bring S0 to S1. This is a question of optimization. What happens is that S1 is different for different computer configurations, and processing needs to happen. Then the question becomes, how much effort do software companies spend optimizing that processing? The answer is "as much as they feel that they need to."
Computer boot times have been constant over many years because performance gains enable companies to add more features. As long as the boot time stays within tolerable bounds for the typical user, there is no need to optimize further. But there are tons of other computer systems in the world (particularly embedded) that must boot instantly, and they do so.
The computer and OS config doesn't change often.
And it's doesn't seem slow to test that.
So caching at boot should work.
And caching is a low effort optimization. So it should have been implemented early.
But we don't have caching at boot, why?
Remember; the computer could quite literally have been completely reconfigured out from under the BIOS. Testing that everything is the same from the computer's point of view is anything but straightforward.
Also, most recognizable boot time isn't spent waiting on BIOS and POST; it's spent waiting for either the boot loader, disk encryption, or the OS to spin up all the background stuff (graphics stacks, session managers, HAL's, message busses, desktop environments, network services... etc) it needs to offer for fulfilling the particular purpose the system is intended for.
Computation is amazingly fast, but by no means either free or magic.
Everything takes time. However, I make no excuses for Windows: They had 3-5 second boot nailed for a while. Then, they done bloated it to the point of unrecognizability.
(And how much does the average computer's config change? How many users never change a single part of the hardware configuration of their computer for its entire lifetime? A hobbyist who built their own might swap out CPU/GPU/drive/ram/etc, but how many people upgrade their laptops in any way?)
Get all that backup stuff spun up. Save the state of the entire computer the same way you're saving a hibernation snapshot. Next boot, just pull that snapshot up. Something makes that snapshot crash? Reset and run the slow boot, either because the system caught this, or because the user held down the "invalidate bootup snapshot" chord.
Although realistically I never reboot my computer any more unless I'm doing an OS upgrade anyway. It's all just "sleep" and "wake up" nowadays for me, so I don't care if bootup adds a minute or two to the end of the half an hour or so my computer spent downloading the update and applying it. Maybe a cold boot just isn't worth optimizing any more.
As in: the os has a flag that says if each file is used in startup. If a startup file is written then the startup config hash is recalculated. It’s a global hash that uses every startup file. If the startup hash does not match the startup hash from the last bootup, then we don’t use the cached config.
Seems straightforward enough to me.
There's more going on during boot than you think. Bootloaders are meant to be small and simple; just enough to hand off to the OS.
If your OS takes a minute to get its stuff straight; there isn't really much you can do to make the boot faster.
It's exceedingly fast. The UEFI implementations on modern computers then have to scan the hard drive GPT to find the bootloaders, if there are any. UEFI Then hands off to the bootloader that then begin initializing the OS. At this point, you're probably anywhere from 5-7 seconds in in my experience. As your OS begins loading, it has to spin up the filesystem, and locate all the necessary files required to do it's thing. Most critical hardware (mouse, keyboard, video drivers) are loaded and initialized at this point.
Generally, your OS would be in some equivalent of a single-user mode at this point.
After the necessary local filesystem shenanigans are complete, non-critical device drivers (network, sound card, exotic storage media) tend to get initialized. Network drives if properly configured might be mapped, but generally (I.e. Windows) loads Most remote volumes after login, which is generally after the system enters multi-user mode.
Windows in particular is incredibly annoying because vast tracts of configuration data is tracked in the registry; an in-memory hierarchical key/value pair binary database. Most "Windows updates" tend to involve shell scripts/installers running and performing filesystem and registry updates while you're sitting there really wishing you knew why stuff was taking so long. Stuff is taking so long because the registry is a bloody mess, and your filesystem is getting polluted by Windows not cleaning up after itself.
God help you if you killed an update in the middle; as the scripts probably were not crafted with a User's convenience in mind, and therefore are likely to fail in exceedingly interesting ways.
Though I habitually try to be the most horribly behaved user in that regard, and I've only encountered a handful of updates that when interrupted had caused Bad Things(tm) to happen.
If you aren't into breaking things for fun and profit though, I'd not advise you doing the same.
Long story short; 5-7 seconds is the absolute longest I'll tolerate for boot from hardware to OS selection. After that, faster boots depend on OS developers to get things going faster.
Cache invalidation Naming And off-by-one problems.
FTFY. ;)
This feature was introduced years ago. What is stopping other OSes from doing the same?
Maybe if you are restricting to software and time from 'hardware ready', but I doubt this is possible from power application. There are a lot of hardware processes that need to take place before any real code can execute, e.g. locking clocks, memory training, etc.
Maybe the 486 was the low end of what you could buy at the time, but not everyone bought a new computer. My parents upgraded their 386 from Windows 3.1 to 95. It was slow, but usable.
Of course it'd run with much less.
That is exactly how I feel about many other regressions in tech!
Including the promises of the internet and online gaming, or when the industry wanted to sell 3D cards but 3D games were uglier than 2D/hand-drawn games for several years..
When I got my 386DX(ha!) I thought the boot process was so much of a hassle that I seriously believed it would just be a matter of months until that problem got fixed and newer computers would be instant on again. Oh boy was I wrong.
I have a revisionist view of Microsoft - I no longer believe their early products of BASIC and MS-DOS were enabling. And Windows got the world stuck in the desktop PC paradigm when mainstream computing was networked, not moving floppy disks around.
Nowadays with Ubuntu and a decent disk I don't have boot speed problems. If I want the machine rebooted then it is all up and loaded where I last left off within a minute. That includes the shutdown with web server, proxy server and networked drives to deal with. So I am asking, does everyone else have a huge boot delay? Is it really something like three minutes on Windows or Apple to shutdown and restart the machine?
Since I disabled IPV6 I don't even need to reboot - it used to start up funny after a suspend, which it does not do now, the network actually works so no reboots needed.
The other performance difference is concerning adblockers. Recently I turned off the adblocker for a website with a form I needed to fill in. Suddenly the fans were on and my machine was crawling along!
Today with free and open source software you can have a modest machine that goes at speed or you can have a paid for operating system and not turn off the adverts to have an experience akin to wading through a lake of treacle. The developer tools seem fine in open source world so I am wondering if going with Windows really is the sane and rational choice for productivity. I can understand having a Windows machine for testing and doing Windows things but for actual work the open source world just has so much more 'professional' productivity. Boot speed being an indicator of this.
Since I only reboot for OS updates (at which point the update process also runs which is much slower), I had to test this out.
My MacBook Pro running the latest MacOS, takes about 20 seconds to shut down, and then 50 seconds to boot again - including restoring the software that was running before shutdown [browser w/ tabs, IRC client, etc] since it does that before hiding the boot progress screen.
I have a cheap laptop (it does have an SSD) that boots from pushing power to a minimal but perfectly usable i3 window manager system in a second.
If you hunt around a bit for things like "atari 800 memory map" you can find diagrams showing how this all worked. In fact on some systems, you could selectively map certain things from ROM into the memory map to get more RAM if you wanted.
Today, the move to put the OS onto disk, the memory hierarchy, and virtual memory eliminate this approach. You basically have to let the virtual memory system map things from disk into some page space, and often things need to be copied into RAM, work their way up the cache hierarchy and be executed somewhere in order to set the system into an initialized state. I've honestly forgotten nearly all of the details so maybe somebody else can provide a better explanation.
So the reason computer can't boot instantly:
1) We have a complex memory system these days that prevent mapping the OS into the memory address space.
2) OS's aren't in ROM anymore. They sit on disk in a state different than when under operation.
3) Simple engineering willpower. Nobody wants to bother to figure it out because once the system is booted it doesn't really matter (with modern sleep modes and whatnot).
I say that only partly tongue-in-cheek. The home machines in that era were right on the cusp; they were complex enough that you could do Genuinely Interesting Stuff with them, and simple enough that you could still hold the whole machine in your head. The instant feedback of REPL being the primary interface, and the almost zero-time cost of rebooting when an experiment didn't work out, made for a spectacular tool for self-learning.
The complex memory system isn't the culprit here. It's one of the easiest parts to set up.
Of course mileage on a laptop with non-quality parts will vary.
1. Hardware
Hardware is a big problem for boot times. Most hardware is poorly standardized, or not standardized at all, or doesn't even follow the standards, or tries to be backwards compatible with older hardware, or is just plain buggy. This means that the initialization code has to poll and retry and work around a whole bunch of things just in case the hardware happens to be slow in responding or gives a weird response. This is the main reason why POST is so godawful slow, and why the initial linux boot sequence takes so long. Apple hardware can boot quicker because they control what hardware is in the machine and can optimize their initialization code for it.
2. Software
The operating system stack is HUGE. There's a LOT of state that needs to be initialized, and most of it is not very efficient (we tend to optimize the runtime operation vs the startup operation of a software package). You absolutely could cut the software component of an OS boot sequence by an order of magnitude, but the development costs would be massive, and the gains pathetic in terms of the work-over-time the machine will do over its lifespan.
3. Protocols
A large number of the protocols we use for inter-process and inter-device communication have poorly designed latency characteristics. Either they are too chatty (requiring multiple messages back and forth to do a task), or have ill-defined timeouts (requiring clients to wait longer than they should), or ambiguous states, or some poorly built implementation has become the de facto standard. This is an area I'm personally tackling.
4. Formats
We use a number of formats for the wrong kinds of things. Appending to a tgz file, for example, has horrendous time implications, especially as the archive size grows.
Now what would really be interesting is if we had the same kind of knowledge about the typical causes of userspace software and distributed systems being slow to start. In my experience, for proprietary software, it's mostly because people inserted random calls to sleep()...
As for anything POSIX, it's because UNIX is shitware; it took a long time to boot decades ago and it takes a long time to boot now, because more garbage has been piled on top.
It's possible for a good operating system to boot in less than a second, however. People have simply been conditioned to accept this unacceptable state of affairs, no different than a TV that takes ten seconds to become usable for no reason other than the manufacturer was lazy.
That said, even CRT had 'boot' time. The screen would need a few seconds to finally warm up and be fully on. But it was still a mind free system, you knew that your were done with the boot process and could enjoy 90% of functionality.
is that why we hear the audio before video is ready ?
Late in the history of CRTs, some units kept the electron gun warmed up whenever the unit was plugged in -- so it was never all the way off. That enabled an "instant on" feature, at the cost of more power usage.
I have a few moderate boot time improvement projects on embedded Linux under my belt. The typical low hanging fruit are hardcoded wait times in boot loader and drivers, unnecessary drivers, unnecessary features (did you know that PPP - yes, the modem thing - support takes a while to initialize?), slow to mount filesystems, bad choice of storing / compressing the kernel, and delays in the init system (run the application as soon as possible instead). More hardcore techniques are various methods to reduce dynamic linker overhead and reordering blocks on storage in the order they will be read at startup.
I guess part of the difference is that you explicitly enumerate all hardware and drivers in a device tree on embedded rather than figuring it out on the fly like on a desktop/server machine.
Magic trick? Open RC + no crapware + lightweight DE
I use no preloading daemons, prelinkers, gold, or malloc hacks
There's nothing inherent to posix that stops us from booting in seconds.
> So it's probable that the check is sequential.
It's a user unfriendly design for the process to be "send request, wait 5 seconds, send request on next channel, wait 5 seconds, send request on next channel, ..." when it could instead be sending requests across all channels rapidly and then that getting a response on a particular channel _activates_ that channel by analogue means.
The Asus PG27UQ (regarded as the current-best consumer 27" 4K LCD) takes almost 20 seconds to start up, presumably to initialize a bunch of state for its FPGA.
Of course, part of that initialisation is self-tests, harkening back to the O.G. POST[0] days.
Developer errors? Not enough testing?
It's to limit the complexity of suspend/resume that a lot of OSes will do things like reinitialize all drivers (e.g. unload/load kernel modules) to try to get the whole system into a known state, but this takes time.
Relatedly, hardware can be added (or enabled) between boots, so whatever conditional hardware initialization was done when booting may result in a state that's not quite accurate later. Furthermore, some of the state (e.g. anything involving system time) will always need to be modified after restore, and that's a state transiston that's less well tested (moving your clock forward hours or days may make a lot of software flake out).
Only if you never turn your machine off. Don't you power off your desktop every day when leaving work?
People do it with VM's, too. I think you were aiming for something physical with no extra software. That was closest thing I could think to it.
As for the software: Hibernate is storing that initialized state.
How much time would something like that take compared to initialization?
Well that wouldn't really work without the PCIe devices also storing the configuration in NVM. If I plug a x16 device into a x4-only slot (as is typical for the third PCIe x16 slot on motherboards that have it), the device needs to know it has to only use 4 lanes, not the full 16.
Ok, so say the controller has some way to tell the devices to save their state, and when powering on they all read from NVM and can just go on talking with each other right away, no further initialization required. Yay!
Except then you power off your machine, and swap that GPU for the new one you bought from your friend. Now the new GPU has the configuration from your friends motherboard, and your bus controller has no idea about this new card... so this is doomed to fail.
Of course this could be worked around by querying the bus for the devices we expect to be there... except that's the initialization step we were trying to avoid in the first place...
EDIT: Ah, sorry, you're saying the enumeration/scanning for changes is what takes most of the time?
That's sort of how Windows quick startup works. It saves the kernel state after startup, and on next startup, it restores it (kind of like hibernating the system). Iirc emacs does something similar with its lisp runtime as well.
And because the BIOS isn't your only state-holder, anything with a controller on it inside your PC holds state, and that is basically everything today. Including external devices, like everything connected via USB (actually those have two controllers minimum, a USB controller which holds communication link state and a controller for the actual device function, like being a keyboard or mouse).
It totals to hundreds of controllers, and it simply isn't feasible to standardize a way for this entire system to somehow store an overall consistent runtime state. That is why plan B is taken: just re-establish that state every time. We call this process "booting" or "initializing".
Why can this not work?
It would be even more interesting to do this on a per-application basis. Atom does something like this to cope with long startup times, for example.
Hibernate (suspend to disk) used to be slow with spinning disks. Even with SSDs, if on a 6 Gb/s SATA bus hibernating my 32 GB laptop would take 32 GB * 8 / 6 = 42 seconds, probably more. And 42 s to resume. My laptop goes from power off to login and Gnome loaded in less than that time. Of course it takes much more to open all the programs I need. That's why I suspend to RAM. Push a button to suspend and less than 10 s to be working again. By the way, it takes extra seconds for the laptop to connect to the Wi-Fi access point or to the ethernet switch. IMHO it's not fully usable until then.
In the following years, I noticed significant improvements both to boot times in Windows and to their "sleep"-type features. I suspect this was motivated at least in part by competition from Ubuntu.
Ubuntu has such tiny market share that I strongly doubt this.
Why does boot time take ~10 seconds? CPUs run in GHz, meaning 10^9 operations per second. That means that booting takes around 10^10 operations. Why that order of magnitude and not any other? Obvious answer is "that's where the optimization efforts stopped", but could it be 10^9 or 10^8?
Obviously booting time isn't just (or mostly) CPU, but the question extends to other peripherals: Harddrives access is in the 10^8 B/s range. RAM is 10^9 B/s. USB ~ 10^7 B/s. Wifi 10^6 B/s. etc. Why does booting, with all it's internal sub processes still take ~ 10^1 seconds and not any other OoM?
The real question is not whether a computer can boot in a second, it's whether it can boot in a frame.
> And mostly software doesn't utilize multiple cores well.
Most software sucks, that's the point of this whole conversation.
However during the boot process I think the IPC will be notably less, because there will be periods of waiting for disk IO and hardware initialization waits.
To zoom out, there are two dimensions here - it's good for software to run at a good IPC, but even better to do the job with fewer instructions.
When I think of all the things necessary to booting; discovering connected devices, loading drivers, setting up memory and permissions, loading filesystem data, starting up the graphics hardware, ... I struggle to think of many things where ‘a few milliseconds’ is not plenty of time. For sure, you might have electrical limitations, spinning disks might take multiple milliseconds, and loading dozens of megabytes of data is not instantaneous, but, really, you've got 16 whole milliseconds in a frame at 60Hz! Is that so much to ask for?
"If I saved all my work, why do I need to properly shut down my computer? Why does it take so long to shut down?"
Eh, it takes from 10-15 seconds on my computer from pressing the power button to getting to GRUB. After that, it's only another 10 seconds or so to boot Ubuntu.
that's nice.
is that on SSD?
I think this can only be solved on an architectural level by introducing "specialization" in a "general" manner. In other words, have a supervising process monitor times and adjust the system to the local hardware and software demands. The adjustments to be good probably require some kind of learning mechanisms, which you also don't want to have in a kernel itself. Just my two cents.
BCE captures this configured Multics hardcore memory image, and saves it to a file in the BCE disk partition. BCE then returns control to Multics hardcore, so it can continue system start-up.
Subsequent (fast) boots from BCE boot the preconfigured Multics memory image, loading it from disk into memory, and transferring into the image, just as was done when the image was first saved.
Receivers work similarly, using PLLs to downmix the signal they want, generally, and while they can begin trying to receive while waiting on it to stabilize, it's usually pointless because you'll just be getting unintelligible garbage from the noise or wrong frequency.
But a typical server BIOS takes 3-5 minutes do its thing. If you're lucky you might be able to disable enough stuff to shave off a minute. Insanity.
I run my most critical piece of home infrastructure (PiHole, of course) bare-metal on an ancient NUC-like thing with a $20 SSD because it boots and is responding to network requests in like 6 seconds.
I know that this was the case at some point when I checked during the Windows 8 years, I don't know if this is still true.
But I do wonder why WBI generation and automatic usage upon first boot isn't more common (or possible at all)...
That exists for a long time now, but is technically not booting.
How much time does it take for a circle to become round? None at all. It happened instantly.
Booting, as in detecting and initializing the hardware, including the RAM, should only be needed when hardware is changed, and even then it should be possible to cache the state of any unchanged parts.