PC Makers Try To Pinch Seconds From Their Boot Times 399
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.
Re:Don't see the issue (Score:1, Interesting)
You might find this video interesting:
http://www.jkontherun.com/2008/09/mac-os-x-on-msi.html
It's showing a Hackintosh MSI Wind... literally instant sleep/wake. Quite impressive.
Blame OS bloat and feature creep (Score:5, Interesting)
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
Re:Standby doesn't waste that much electricity (Score:2, Interesting)
>Distressingly, my Mac Pro takes 40W when "turned off"!
Yeah, since I normally have around 5 computers in my work room I've installed a master power switch. That switch paid for itself in half a year by power savings alone.
my 5 second startup (Score:4, Interesting)
I got sick of these outrageous boot times a long time ago.
here is how i fixed it:
I have an old IBM PS/1 that i picked up in the early 90's. (for the kids: 386 processor, 2 megs of RAM)
When I turn it on, the system is usable in about 5-10 seconds.
I can have a word processor open AND be typing away happily within 15 seconds of hitting that button.
now it takes me a minute to load my OS, and another 20 seconds before my word processor is usable
what the hell happened?
Linux can boot in 5 secounds (Score:3, Interesting)
In short it's about some Intel hackers makes Fedora boot in 5 secounds on an EEE PC, not exactly the best hardware.
Re:3 stages to tackle.. (Score:1, Interesting)
I am estimating that over half of my XP64 boot time is loading up crap that has nothing to do with the OS. As already mentioned, iTunes has its bootup horseshit. My webcam has its bootup horseshit. Games have DRM bootup horseshit. A good chunk of the software I have installed have their phone-home bootup horseshit. My motherboard driver package even installs several bootup horseshits whenever I grab an update. Video card drivers? Ditto.
The sad thing is that I have given up on monitoring it. I no longer care enough to police it because it is a never ending battle. Some programs, even when you remove their bootup horseshit, simply put it back in the next time you use that program.
An alternative OS isnt the answer because I like backward compatability. An OS that makes this horseshit more visible is. The startup process should be protected, yet apparently it isnt even on Linux or OSX.
Here in windows land, if I look at whats loaded during startup (msconfig) I get uninformative information for programs and services, such as "NvCpl: RUNDLL32.EXE NvCpl.DLL
Lets not even mention the "services" listed with msconfig, where I can't even get a program path or filename of any kind.
Even something very simple could be extremely usefull, such as whenever a program sticks something in startup/services I get a prompt which allows to be place my own note about what I was doing when this happened, attached to the horseshit that got placed there, so that I can look at my own notes such as "nvidia display driver installation" so that when I run msconfig I can make rational decisions about the item in question.
8 bit (Score:4, Interesting)
My Sinclair ZX Spectrum is ready in less than 2 seconds. Now I have made an ethernet card for it, I can be on IRC within 5 seconds of power up!
Re:I don't understand. (Score:4, Interesting)
Obviously, we must stop using using pansy C/C++/Java/Ruby/etc... languages and go back to writing everything in assembler. Then boot times will rock!
Duh.
Maybe you intended for a funny, but i'd rather give insightful if I had points. I can't forget the wonderful playing experience with ELITE [wikipedia.org] on Commodore 64... and those days it was all machine code!
Nowadays the philosophy is that you can afford to be a sloppy programmer and use absurd languages (VirtualBasic?) just because Moore's law will eventually compensate... given a year or two.
It's the time it takes for a human to notice (Score:5, Interesting)
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.
Re:Linux can boot in 5 secounds (Score:5, Interesting)
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.
OSses should sleep/hibernate by default, like Macs (Score:3, Interesting)
Re:I don't understand. (Score:3, Interesting)
Re:I have in mind my Apple G4 Powerbook (Score:3, Interesting)
I'd be interested to know what the consumption would be when measured with a power meter.
My Macbook pro (battery almost 3 years old) gets about 72 hours of sleep time with intermittent wakeups for quick email via wi-fi. I would not even attempt that with my ubuntu thinkpad - unfortunately.
Re:I don't understand. (Score:3, Interesting)
Come on, BeOS fanboys. Tear back the nostalgia and BeOS was awful. Everything from disk I/O performance, networking, graphics was miserably slow. It was an OS designed to give good demos to get more investment capital. There was no reason to actually /run/ it and then live with it in the real world.
Pervasive multi-threading is premature optimisation bullshit, built in to the core of the OS. That BeOS fanboys loved this shows how much they're really related to ricers rather than actual users. The strategy in "pervasive multi-threading" is "if we're not sure how to fix it, add more threads". Threads of course, as any developer ought to know, add overhead. In a simple application this strategy means that you have one thread and one window. So you're in the same boat as on every other OS. Feeling excited and special yet? You shouldn't be.
Now if you add networking to the program you get one thread per connection. (Everyone who has ever worked with network software slaps their forehead at this point). But that's not the most fun thing. If you add a window, just a humble, probably not even particularly UI dense window, then you get another thread for that. "What for?" I hear every sane person ask. Well, because it was simpler for Be's engineers that way, and the ricers like it. However if you add sixteen tab widgets each with a dozen other UI elements in them, well, no extra automatic threads for that, you'll have to design your own multiplexer if you want one (good luck)
On any other OS you can divide stuff up nice and easily, maybe you've got a ton of lightweight UI, some code shuffling data over the network and a heavy compute load, so you give them one thread each. Simple. BeOS won't let you do that. It makes its own decisions about threads, and you'll have what you're given or else. As well as frustrating any programmers on their own platform (including their own engineers) who knew what they were doing and didn't want all these superfluous threads, its a portability nightmare. Programs from other platforms obviously don't have one thread per window (why would they?) so everything with a GUI is a bear to port.
Meanwhile, because you've got all these superfluous threads that need to communicate with each other and with the OS, every application is sending lots of messages, but again Be's engineers took the easy way out, when a message queue fills up they just drop the messages. So sometimes, when things get busy, your app will lose vital messages and get confused. Awesome.
That's why I say "premature optimisation bullshit". Who went out and profiled hundreds of applications to see whether adding one thread per window was the right approach? Nobody. The engineers hit a wall, and saw "one thread per window" as a way around that wall that every other OS just scaled. And then they sold it as a feature and couldn't admit failure by going back and fixing it. Next week: Why giving every user full system privileges is actually a "good thing" and why you'll never need more than 1GB of RAM, from the creators of BeOS.
And don't bother to tell me that Haiku (a reimplementation of BeOS) somehow "proves" that BeOS was good. People reimplement almost /everything/ there are guys out there cloning OS/2, NeXT, Amiga, Windows of course - even people trying to make a new Commodore 64. Haiku is nothing special except maybe it can get a Guinness record for taking more than seven years to produce an Alpha.
Re:Why don't more people use standby? (Score:5, Interesting)
> 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...
Re:I don't understand. (Score:3, Interesting)
Speed is still an issue. A modern hard drive can do sustained reads of about 50MB/s in a straight line, and about 100KB/s on random reads (worst case is around 56KB/s). A modern computer typically has at least 2GB of RAM. If you store the RAM in a contiguous block on disk, you can load it all back in 40s. If you've got 4GB, it will take 80s, and if you've got 8GB you're up to 160s. Much slower than a complete reboot, but doesn't lose any state between powering off and on again.
Demand paging slows this down, because you are no longer doing contiguous reads. The advantage is that most of your 8GB is not likely to be the working set. For one thing, anything that's disk cache or mmap()'d files doesn't need to go into the hibernate file, it can just be dumped back to disk. This will slow things that access the disk down, but increases un-hibernate time. Beyond that, most operating systems will speculatively sync pages that have not been recently accessed with swap so that they can be evicted quickly if something else needs more RAM. If you only dump the pages that aren't already in swap into our hibernate file then you will end up with a much smaller set which can be quickly read back in to RAM.
Forget computers, how about everyday electronics (Score:4, Interesting)
Why does it take the Wii a good 30 seconds to start playing a game from the time you push the power button? (I'm including in here the time it takes to acknowledge the safety warning and click through the Wii menu.) I'm sure that the 360 and PS3 are just as bad.
And (probably unique to the Wii), why do I have to see one or two more safety warnings every time the game loads?
And (definitely not unique to the Wii), why do I have to watch multiple studio logos before I even get to the start screen. The record that I found, was one game that had EIGHT studio ads!!
But, how about DVD players. My player takes somewhere in the 20 second range to load a disc and then I have usually a few (usually) skippable ads followed by 10-15 seconds of unskippable menu animations.
I'm still holding out on Blu-Ray because one recent review of a new Sony player was talking about how fast it was - 1 minute to start up - 1 minute to load the disc. That's two full minutes before even the ads start to play!
I kinda miss the 80's, when you stuck your VHS tape in and the movie started right away. Any ads? Then just rewind back only to the start of the movie and you'll never see them again. You took Super Mario Bros and put it in your Nintendo. In under five seconds, you're asked if you wanted to play with one or two people. After you make that choice, within a second you're playing the game.
Re:It's the time it takes for a human to notice (Score:4, Interesting)
On RISC OS [wikipedia.org] to reset many of the BIOS settings (the ones normal fiddling is likely to screw up) you held down R as you switched the machine on, to fully reset the BIOS (to the point that you had to tell the machine it had a floppy disk drive again) you held down Delete. It started up to the GUI, ready to use, in about 10 seconds. Wikipedia says the record is 2 seconds.
A 1999 RISC OS [everything2.com] machine would go from power-on to a running web browser in 16 seconds.
Likewise, my phone manages to start up in less than 10 seconds, with another 5 or so if I try and immediately load the web browser.
Vista doesn't respect it (Score:2, Interesting)
Plenty of ways to get smart here, but we are lazy (Score:2, Interesting)
Well, the wish to boot fast is actually under attack from many corners. First off, if you want to boot fast you have to scrap the proprietary BIOSes, or over-intrusive BIOSes altogether. BIOS as we still have it now, is a remnant of the past. Granted the first instruction the CPU does when machine is hot-powered comes from the BIOS-owned storage. And 'owned' is the keyword here. We are still dealing with closed-source BIOSes, and they also do like to take their time.
Most of the services they provide are today irrelevant and rudimentary. So part of the solution is to minimize time spent in BIOS bootstrapping. Apple does it partially with its EFI-like OpenFirmware, and Intel has sort of caught on with their EFI too. So it is true that Apple people are living in the future. We only have BIOS because apparently someone needs it. But I am sure these folks are nowhere near the mass of people who just simply cannot understand why we still have those ancient cemented irreplaceable proprietary blobs of code on modern motherboards. Granted motherboard makers tweak their own little quirks like buggy ACPI tables etc in their blackbox-like BIOS ROMs, but then this is yet another reason to get rid of this culture. I may be idealistic, but Linux caught on, and I think BIOSes will go away soon too.
Another thing I see is research into compilation techniques and software analysis. This has a bit to do with the usual cry for "do it in assembler if you need speed". What this essentially means is that manual human labour in assembly language deems faster leaner code than that same assembler code spit out by a C compiler for instance. The truth is, the compilers are still introducing runtime overhead, which ideally they should not, especially considering that C was designed to translate into RISC/CISC fairly strictly, i.e. a sort of zero-overhead principle compared to manual assembler skills. So the solution is to make more complex compilers which will deal with overhead more efficiently. This will compensate for over-intrusive C programmers that like to abstract their software to the point where their C programs look like a mutated object oriented C++ template mess, painted with macros. I have seen it, and it does look ugly, no wonder the finite-state-machine compiler has no chance whatsoever to claim zero-overhead then.
A bit related to the above is a technique which will take advantage over parallel processes in hardware. Someone here claimed that Asus EEE starts much faster much thanks to its solid state drives, which do not have to spin up. This is simply incorrect as a reason. First, a modern harddrive spins up in a second on average, which is hardly a big deal compared to the overall boot time. Second, it is simply the inability and inflexibility of a bootstrap routine to account for this spinning-up time and do something useful while the disk spins up. This spinning-up hardly blocks the CPU, or other peripherals. So in essence, we are again to blame only ourselves as programmers who are unable to parallelize the bootstrapping efficiently. Incidentally since an Intel x86 CPU is super-scalar and benefits greatly from it, there is no reason we cannot make compilers that emit superscalar software - software that also does out-of-order execution of independent code paths in parallel.
We are just lazy. All we want is to sleep, fuck and eat. The rest comes after. Faster boot up time of our computers is not very important, it is just a small nerdish annoyance :-) There are critical annoyances like bad expensive closed-source software, and then there are the "slow boot" annoyances.
Re:So... (Score:2, Interesting)
I cut down on my startup time by buying a new harddrive that didn't come without all the preloaded drivers and crap and reinstalling the OS. My dell now loads in approximately 45 seconds. Which admittedly is a little more than the "optimal" 20 second time, but it much better than the 3 minutes I had to wait before.
I shaved ~2 minutes off my Thinkpad's boot time into Windows. How? I uninstalled the fucking mouse driver. Seriously.
Other vendors are even worse. Don't even get me started on Toshiba.
Re:So... (Score:3, Interesting)
well, for my laptop their equally important. IE, can I check my email between flights, and how much of my precious battery power is gone (or if I used up all my battery on the last movie, will their be enough residual juice to book that hotel change without a hard crash.)
Granted just drop a extra few hundred on a smart phone+ addtl $30 monthly service plan, or fly business/first class = a slow power cycle time costing a few hundred more per year.
Actually a slow shutdown time cost me a laptop, I hit shutdown but didn't have time to wait for verification, something hung with a BSOD staying in a high power mode + enclosed space + battery draw, it overheated big time the screen and hard drive failed shortly their after. Had it always shutdown in 10 seconds (like my linux eee pc) I would notice.
Lets go back to ROM (Score:3, Interesting)
Re:So... (Score:3, Interesting)
It would make more sense to sub-divide the printer driver into twenty or thirty drivers, one for each format, and only load the one or two drivers you actually use, that way it only occupies ~2.5 megabytes of RAM rather than 50.
In addition the drivers would only load as needed, rather than at bootup. I don't even own a printer, so having the printer driver loaded is silly.
5 Seconds. No more (Score:3, Interesting)
"It's not about booting faster, it's about booting in 5 seconds."
http://lwn.net/Articles/299088/ [lwn.net]
http://lwn.net/Articles/299546/ [lwn.net]
or a bit more involved:
TCCBOOT compiles and boots a Linux kernel in 15 seconds
http://lwn.net/Articles/108341/ [lwn.net]
Re:Faster Boot Times.. (Score:2, Interesting)
I still blame boot times on the end user loading up their computer with a bunch of crap (or the PC maker-- which of course is the reason I never buy a brand name PC and always build my own).
No big (Score:2, Interesting)
-intel q6600
-asus p5q deluxe
-4 gigs of ram (gskill)
-old harddrive from 2003ish (one i bought failed)
-windows XP pro (runs in selective startup)
My boot time is 22-26 seconds, even with my old junker hard drive, with a new one I expect that number to drop. You just need to turn stuff that you dont use off. I'm considering using a solid state disk for the OS, and a traditional high capacity HD for apps. I think that will help drop it atleast 4-5 seconds, but I dunno.
Re:So... (Score:5, Interesting)
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?)
Longer boot times = sometimes good (Score:1, Interesting)
I worked in an election campaign in the recent election in Canada. The rental company sent the campaign office a bunch of computers that performed suspiciously poorly and crashed a lot -- the reason? Bad RAM. So bad, that as soon as I turned off ultra-quick-POST, the cursory memory check found it and halted the system.
I always leave the memory test turned on for boot, even though it takes a little while with multiple GB's of RAM for two reasons:
1. If RAM has somehow failed, it might find it.
2. Testing the RAM blanks it, which means there's less chance of someone being able to cold boot the system and try to recover passwords out of the RAM before it fades (/. ran a story about that a few months ago I think).
Eight Seconds for MS-DOS (Score:3, Interesting)
Linux suggestion: save ASCII config file timestamps and corresponding kernel structures. If the ASCII config file is unchanged, then reload the internal structure without any recomputation.