31–40 of 167 posts
A lot of these answers are why computers don’t boot instantly but none really talk about why they can’t . The accepted answer talks about it on a physical/mechanical level but eschews practicality: what can’t computers boot arbitrarily quickly?
A lot of these answers are why computers don’t boot instantly but none really talk about why they can’t . The accepted answer talks about it on a physical/mechanical level but eschews practicality: what can’t computers boot arbitrarily quickly?
They can. But the more software you need to initialise the slower it is. And modern machines run a lot of software.
Of course, part of that initialisation is self-tests, harkening back to the O.G. POST[0] days.
A lot of these answers are why computers don’t boot instantly but none really talk about why they can’t . The accepted answer talks about it on a physical/mechanical level but eschews practicality: what can’t computers boot arbitrarily quickly?
They can. But the more software you need to initialise the slower it is. And modern machines run a lot of software.
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.
I have a question too: why does radios take so long to start up and acquire a signal? Same for other I/O devices similar to radios，on the embedded side you have keep on polling until finally it acquires the signal.
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.
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.
Earlier quoted context omitted.
They can. But the more software you need to initialise the slower it is. And modern machines run a lot of software.
But then the questions are, why does it need to initialize? Why doesn't it start in an initialized state, what factors make it impossible to determine that initialized state beforehand and storing it? How close can we get?