Slashdot Mirror
Why Do Computers Take So Long to Boot Up?
An anonymous reader writes "Computers take too long to boot up, and it doesn't make sense to me. Mine takes around 30 seconds; it is double or triple that for some of my friends' computers that I have used. Why can't a computer turn on and off in an instant just like a TV? 99% of boots, my computer is doing the exact same thing. Then I get to Windows XP with maybe 50 to 75 megs of stuff in memory. My computer should be smart enough to just load that junk into memory and go with it. You could put this data right at the very start of the hard drive. Whenever you do something with the computer that actually changes what happens during boot, it could go through the real booting process and save the results. Doing this would also give you instant restarts. You just hit your restart button, the computer reloads the memory image, and you can be working again. Or am I wrong? Why haven't companies made it a priority to have 'instant on' desktops and laptops?"
"Why can't a computer turn on and off in an instant just like a TV?"
My new HDTV takes about a minute to boot. Something about an ATI bios
I triple boot NetBSD, FreeBSD and x86 Solaris on my old desktop with an Athlon XP processor, and 512 MB of RAM. I don't recall off-hand the exact processor speed.
Regardless, NetBSD is the fasted of the three. It takes a little over 6 seconds from power-on to the login screen. FreeBSD takes 11 seconds. Solaris is a bit longer, clocking in a 14 seconds. I know these times because I was curious of this question as well, and so I did the timings. All three systems are basically the default installs, plus whatever initialization file changes there have been from installing various pieces of software.
Solaris does start into X, so that may be why it takes longer. Still, adding the 2 or so seconds it starts to get X running, NetBSD and FreeBSD are still less than Solaris.
I've spent a lot of time using Windows in virtual machines. For VM platforms that provide on-demand block allocation for virtual disks you can see a typical Windows boot do wild things like write to 250MB worth of blocks that were previously unused (i.e. the virtual disk grows by 250MB). NB: I'm talking about an ordinary boot, not one following installation of anything. It gets harder to see as virtual disk occupancy increases but it's an eye opener.
Indeed.
In the beginning, say from Edison's development of the electric lighting system, through the invention of the fractional-horsepower motor which enabled the development of home appliances such as vacuum cleaners and washing machines, most things started up in a fraction of a second.
Then came vacuum-tube-based electronics, which took a minute or two to warm up.
Then came the "solid state" revolution, and, once again, things started up instantly. WIth the exception of television sets, which had a vacuum-tube-based "picture tubes" in them. However, manufacturers soon developed circuits that kept a small amount of current flowing to keep the filament partially warm while the set was "off," producing "instant-on" televisions.
Early hobbyist computers were instant-on, too. Before diskette drives were common, the machine had everything it needed to boot stored in ROM and was up displaying some kind of welcome prompt within a fraction of a second. Even when the serpent entered Eden in the form of "operating systems," startup was quick. When you turned on an 48K Apple ][+ with a diskette drive and spiffy Apple DOS 3.3, there was a brief "whish" as the disk spun and loaded a few K of code into the processor, and there you were.
It seems to me to be lazy design that says that booting consists of more than loading code into RAM and establishing state for the internal hardware. I have no idea why OSes must churn away for big fractions of a minute _running_ code. Why can't it just load a snapshot of the desired final state of RAM?
What really gripes me is that lately Windows and Mac OS X have taken to presenting an empty _illusion_ of a faster startup. What seems to be happening is that all the minute-long processes still churn away, but the processes that present the UI run in parallel. The result is that the visible desktop gets into a displayable and interactive state quickly. But while the UI seems to be ready, nothign else is... particularly anything to do with the local network. If you actually try to do anything on that desktop, you still encounter minute-long delays.
"How to Do Nothing," kids activities, back in print!
(I hope I have this story right...this is from memory)
The story goes that the engineer working on the boot sequence for the original Mac was working late one night when Steve Jobs wanders past and asks how long the thing takes - the engineer is pretty happy that he's gotten it down to around 30 seconds (or however long it was) and that's probably good enough. Jobs then comments that they'll probably sell at least a million of these things - and each one will probably be booted a couple of times a day - and the machines will last maybe five years - so if he can save just one second more from the bootup time - that's equivelent to 113 years from the lives of Mac owners. So if you can save just one more second - that's like saving someone's life.
Talk about pressure!
But it's a serious point. The amount of human lifetimes that are wasted waiting for PC's to reboot is pretty horrifying - and there's a lot more than a million of them. Someone should take this seriously.
www.sjbaker.org
I find XP refuses to hibernate with more than about 600MB of active memory; it makes an attempt, then returns you to the desktop with a popup bubble saying "Insufficient resources exist to complete the API". This necessitates me closing all my apps before each hibernation, and after a week or two even that won't work.
:)
Anyway, I remember using something closer to what the story is talking about, on the Amiga of all places; FastBoot had you boot normally, then save a snapshot of the system at the end of the startup-sequence. Future boots would use this snapshot, which you generally didn't want to update at each shutdown -- you got 2-3s boot times, but each boot was clean. It worked surprisingly well for a scary hack
Of course, it should be noted that there IS a way to have Windows leave the hibernation file alone unless you tell it to hibernate again; that is, a hibernate once, resume many kind of situation. It's a trick often used when building a car PC. You get the system to the point where you'd want the system to start from, then tell it to hibernate. From then on, it'll resume from that spot. If you can get your system to work properly with hibernation, it's just about as fast as you'll ever get it to boot.
My sig can beat up your sig.
The problem is old-school linear thinking we've inherited.
There is no technical reason that a computer could not wake up, verify the keyboard, memory, hd, mouse and display are the same (in a few microseconds, probably) and be up and responding very well to the user, while (new concept, brace yourselves) the computer carefully brings up other hardware subsystems and makes them available as they become functional. You could be in a word processor, graphics editor, all manner of things that don't require more hardware until you do something like print or attempt to access the network; if those subsystems are not ready when you try to use them, the design would allow for [establishing hardware, wait or cancel] and there you have it.
There is no problem whatsoever with plug and play concepts coexisting with fast usability other than current design shortcomings end users have been forced to live with. The computer is running as soon as the HD is spinning, memory sized, and the video card is on and the KB and mouse work. Just because current operating systems don't let you begin working at that time isn't a reflection on plug and play as a concept, it's a reflection of linear thinking that descends from old single tasking systems like early DOS.
The idea that a 2...3 GHz 32 or 64 bit CPU cannot bring itself to decent usability in under a second is one that is silly right on the face of it except in that common systems are using old school thinking and layering more and more crap on top of that thinking. There is not a thing in the world that says drivers can't be loaded on demand, or after usability from boot, or separately. Nothing.
I've fallen off your lawn, and I can't get up.