Slashdot Mirror
PC Makers Try To Pinch Seconds From Their Boot Times
Some computers are never turned off, or at least rarely see any state less active than "standby," but others (for power savings or other reasons) need rebooting — daily, or even more often. The New York Times is running a short article which says that it's not just a few makers like Asus who are trying to take away some of the pain of waiting for computers, especially laptops, to boot up. While it's always been a minor annoyance to wait while a computer slowly grinds itself to readiness, "the agitation seems more intense than in the pre-Internet days," and manufacturers are actively trying to cut that wait down to a more bearable length. How bearable? A "very good system is one that boots in under 15 seconds," according to a Microsoft blog cited, and an HP source names an 18-month goal of 20-30 seconds.
My later Amigas typically had a boot time of 10 seconds. Full blown AmigaOS on an internal HD on the A3000. I miss them dearly.
We've managed to stav off the usefulness of moore's law by creating the world's worst software to run on them.
It's not fair to judge modern systems with those older ones however; we ask a lot more of our software and our GUI's than we once did. But there is no excuse in the way that windows configures itself by default, it sets itself up for failure by having a re-sizable swap partition on the main OS partition.
When I install Windows on a new PC, I always create 3 partitions: An inner partition of 5 - 10 GB for a fixed size swap file only, then an OS partition, then an applications partition, and defrag regularly. I can keep my machines going for many years without much performance degradation in this manner.
Even if you are scrupulous, bad software and bad uninstall jobs will eventually bloat out your system a little bit.
A little common sense goes a long way, unfortunately those who do not deal with computers for a living aren't going to know these little tips and tricks, and will continue to be frustrated. OS manufacturers, in particular windows need to set up a default OS install for success, not failure. Software manufacturers need to create very clean installs and uninstall routines. Unfortunately this is not always possible in the OS environment. It's a joint effort.
The tin-foil hatters will think that M$ is doing this on purpose so people will feel compelled to upgrade more frequently, but I don't really give them that much conniving intelligence.
--Mike
"If it took long enough for you to notice then something must have been wrong"
Actually that is one of the reasons why things are still slow in general - because though CPUs and hardware get faster and faster, we're still living in a human world. So the "human notice" times remain important.
Lots of programmers have their programs wait for one second if they have to wait a minimum time for hardware or for other reasons, after all most seem to think "it's only one second".
A few 1 seconds here and it all adds up.
Silly? Maybe in many cases, BUT often you really do have to wait in seconds because it says "press ctrl-A for SCSI controller config" and so if the computer does not wait _seconds_ for the human and only waits _milliseconds_, the human is also going to be pissed off.
For a similar reason a windows PC can't boot faster than the X seconds for you to press F8 to enter "Safe Mode". Well it can, but it'll have to be "hold F8 down while booting", and that means some changes in the keyboard hardware and config stuff, some user education etc etc.
Also often the threshold for determining that something has gone wrong is more _human_ related. Say a hard drive has gone slightly flaky and takes a bit longer to spin up for whatever reason.
How long will a human wait for a harddrive to spin up? Pretty long in many cases. Even if it takes 30 seconds, they might still wait.
The BIOS could just assume it's dead, after all it's not behaving like a _normal_ hard drive. But the specs for _failure_ are often human related - they are determined by how long it is expected that a human will wait.
It's just like network connectivity timeouts are in the order of tens of seconds. Instead of say minutes. A tree might be willing to wait minutes or even days, but most humans don't want to wait minutes.
They're not in the order of milliseconds because the speed of light is too slow (light takes more than a few milliseconds to cross the world) and people are willing to wait seconds.
The eee is one of the best machines for getting a fast boot time tho...
It has a bios that's capable of caching the power on state (so it doesn't have to run the normal tests every time), it has a static hardware configuration so it doesn't need to spend a lot of time probing for hardware, and it has solid state disks which don't need time to spin up.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
> I've been using standby/sleep extensively on my desktops and laptops for the last 10 years,
> and I still can't understand why people with a modern machine don't use standby.
Because it still doesn't work for everyone. I tried it a month ago, followed the instructions in the suspend HOWTO, made that suspend script and ran it. The machine suspended, but didn't resume - everything spun up, but looked dead. Sure, it might be easy to fix, but doing so would entail poring through hundreds of forums posts written by clueless idiots for that one little bit of information, followed by dozens of reboots for test-fail-retry cycles. I might get around to it, when I have a month to spare. Many things on Linux [don't] work like that...
This is sooo close to the overall truth to why Windows (and Linux) take so long to boot.
The systems in the DOS world were hard-coded via boot / initialization files to load exactly the hardware drivers for the hardware configured in the machine. Hardware was hand configured by a person, set to IRQ/DMA/Memory addresses that were generally accepted as appropriate, and conflicts were reconfigured manually. The autoexec.bat and config.sys files were manually tweaked by hand to reflect the different cards - and Boom! it all loaded lightning fast because it was simply following instructions - computers do this very well.
Current OSs have a gazillion different permutations of hardware that could present when they boot each time and they have the drivers for all the hardware present. They interrogate the hardware, every subsystem they can find on the different places that could have hardware and then one by one they load the different drivers for the cards, dynamically allocate the hardware (Plug n Play) with IRQs and DMAs and Memory locations and try it out to see if it works, try again if it doesn't. But it's a matter of 'Hello PCI slot #1 - what kind of card are you?' and then negotiating the drivers, hardware allcations, etc. That's why you can install the drivers for two different video cards, and each time you shut down / restart the system you can swap the video card for the other one and - the system boots up and works nicely - that's one nice benefit, the other benefit being that it's "easier" for the common user to get a system up and running.
The above is the reason that ultra-fast hard drives don't really make much difference in boot times, why stripping out processes make some but not a ton of difference - because the hardware interrogation / allocation / driver load process is not a particularly quick endeavor.
If we had a way to hard-code the list of hardware, and even the resource allocation (IRQ / DMA / Memory locations / etc) that the computer is running and guarantee to the OS that it is the same each time the system boots - that OS could boot a LOT faster than current systems boot. It might possibly be a way to boots that are faster than restoring a 'hibernate to disk' session because a 'hibernate to disk' session has to restore the complete system state regardless of system state, meaning it actually has to populate the entire system state including swap file, etc. A hardware boot with a predefined system configuration can configure the system and load the drivers for the base OS, leave the rest of the system basically uninitialized for use by programs as they allocate the memory once the user logs in and starts running programs.
It's one step backwards, and three steps forwards. Worth it? If someone decides so - go for it (just give me credit for the idea - that's how GPL works, right?)
Glonoinha the MebiByte Slayer