Software Tweak Makes Linux Boot In Under 200 ms

An anonymous reader writes "A version of Linux has been created that radically speeds up system boot time -- to less than 200 milliseconds (ms) from power-up to application code startup. The techniques, created by Real-time Linux vendor FSMLabs, are processor independent, and boot times of under 100 mS are expected in the future." Update: 09/30 01:04 GMT by T : Yep -- both headline and post should have read "ms" (milliseconds) rather than "mS" (milli Siemens); thanks to all the alert readers.

Comments

Only for embedded devices

[Professor_Quail]

This isn't for desktop linux, only for embedded devices.

Re:Only for embedded devices

[wo1verin3]

>> Perhaps the instant-on concept confuses you?

No, it's not a matter of confusion, the parent seems to be deciding to use Windows vs Linux based on the bootup time which is silly. There are tools for every job. Sometimes it is Windows, sometimes it is Linux.

The alternative I suggested was to use suspend, a better option would be hibernate perhaps where the laptop is completely powered down. The Ram contents are written to harddisk. On an ACPI system windows begins loading and sees that it was in suspend and loads the hibernation file into ram, or APM where this function is controlled more at the bios level.

Re:Only for embedded devices

[danheskett]

Windows does exactly that for its "hibernate" feature. Essentially hardware is returned to a safe state (write operation suspended, etc) and the contents of memory written sequentially to a block of disk space. On boot, a small stub is loaded, which copies the data from disk to memory. Execution resumes at that point. The last thing that Windows does before hibernating is to schedule hardware re-initilization in a short period of time - essentially ensuring that things like sound cards, video cards, USB devices, etc get a "soft" reset when out of the hibernation period.

On a decent reasonable recent PC this takes a few seconds. On my fast AMD box I hit the power button and about 2 seconds later the box is off. Hit the power button again and its back on in about 4 seconds exactly where I left off. If I lost my DHCP lease in the interim it takes another 3-4 seconds for network connections to resume.

But whats best about the changes MS made to Windows XP is the multi-threaded boot process. Other than the kernel load the userland stuff is mostly all multi-threaded even on boot. This means services and whatnot are starting concurrently without waiting for other things to finish. Its somewhat less safe - a failed service could potentially cause others to hang and lock the system and/or cause a reset - however, I've yet to see that problem in the field. The net result is that on a typical AMD/P4 Windows XP box you can get to a login prompt/welcome screen in under 30 seconds, often under 20.

Users I've switched from XP to various Linuxes have all complained about the boot times - Red Hat 8 on similiar hardware takes eons to get a graphical login prompt. SuSE is just as bad. Mandrake is somewhat better, but all are in the minutes not seconds metric.

Re:Only for embedded devices

[Anonymous Coward]

There is no way a linux desktop machine should take anywhere near 7 minutes to boot up.

Take a look at what services are starting up. You should be able to disable most of them. Also check for any network connections you aren't using. Redhat has an annoying habit of hanging while waiting for a dhcp response for all network devices unless otherwise configured. After a little while it will give up and continue. Disable those unused network devices.

Sendmail can sometimes take a long time to load too. Most likely you can disable it.

After you trim off all of the unused services your startup should be back down to a minute or two.

As a nice side benefit, not running sendmail, ssh, rpc, apache, telnet, ftp and such will remove nearly all possible remote root exploits.

incredible

[alienhazard]

this is certianly incredible, but it is not yet available for x86 platforms. Do note, that this is not the boot sequence up till you get the login prompt, but just the initial loading of the kernel.

NOT Only for embedded devices RTFA

[Anonymous Coward]

RTFA
"Yodaiken said the new fast boot technology also supports many Intel x86 boards"

Re:NOT Only for embedded devices RTFA

[mcspock]

Did you read the article? This was only in the context of EMBEDDED devices, and there are MANY Intel x86 embedded boards. These are very different from desktop linux, with the myriad of devices your standard PC has.

Re:NOT Only for embedded devices RTFA

[jonadab]

Nevertheless, it's clear in the article that we're only talking about
kernel boot time here (which is usually about five seconds). The
_other_ three hundred seconds your system spends booting (starting
all the services and stuff, then X, then your desktop environment,
then any apps) are unaffected.

They (re)invented XIP?

[Dancin_Santa]

It works by loading the OS to RAMDisk from Flash... Sounds like eXecute In Place.

Not the most original thing in the world, but definitely necessary to keep Linux in step with other heavy embedded operating systems like WinCE and VxWorks.

kernel boot != complete system initialization

[Ankh]

Note that for embedded systems the main interest is how long it takes for the kernel to load, not how long it is before a multi-user server or workstation has a prompt that says "login" on a pretty X display.

So, this is a good improvement it seems, but shaves away 4.5 seconds or so out of maybe 30 sconds or over a minute for many people. Combined with the parallel init scripts work mentioned a few days ago,though, I'm guessing that Linux systems will be booting a lot faster with the major releases in 6 months to a year.

Re:Slightly off topic but about *nix boot times

[gordyf]

Linux starts its services before it brings up the password prompt. Windows loads, displays the login prompt and continues starting services in the background.

Booting Linux Faster through Blocking

[Eponymous Cowboy]

Although this article refers to embedded systems, the earlier Booting Linux Faster article contained an overlooked post by TornSheetMetal, who had a great idea on how to make Linux, or any operating system start up faster on any system.

Simply run every startup script simultaneously, but have each script block until its dependencies have started. Nothing waits longer than it needs to, and there is no need for additional complex systems to check and manage dependencies.

This is VERY easy to do with daemontools and svok (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.

Re:Booting Linux Faster through Blocking

[targo]

imply run every startup script simultaneously, but have each script block until its dependencies have started.

Btw, this is pretty much what Windows XP does, that's how it achieves a much better boot time compared to earlier Windows versions.

Re:Booting Linux Faster through Blocking

[FooBarWidget]

Havoc Pennington said he already tried that before, but the end result was *slower*, not faster. Basically, it's because of disk seeking time. Harddisks are slow. Simultanous loading will result in a seek storm which makes everything load noticably slower. The same is true for applications: if I try to load Galeon and Mozilla Mail at the same time, the total time is higher than when I load Galeon, and then Mozilla Mail.

Re:Booting Linux Faster through Blocking

[Anonymous Coward]

That's why it is necessary to do what Windows XP does: each time it boots, it records the order of sector accesses. Then, when it is later idle, it reorganizes those sectors to optimize them for the next boot--a much smarter form of the traditional "defragmentation." The result is a recursive iteration to the optimal sector organization, and the fastest possible boot. (Incidentally, it also does this while loading each individual application, which is why applications start so much faster under XP than 2000.)

WTF?!?!

[monkeyboy87]

Why do we care how long it takes to boot something that can have an uptime measured in months and years??!?!?

oh wait. these are embbeded systems for things security, monitoring equipment etc. yeah i can see reboot times being critical.

And everyone knows...

[Kashif Shaikh]

...Windows might boot faster, but as we all know windows has D.S.S. capabilities which means "Delayed Service Startup":)

In other words, it loads everything AFTER you login, no joke;)

Want a faster boot? "Make" it so.

[yerricde]

Problem is dependency but I've seen some quite good solution to this.

If you want to make some daemons run, and some daemons depend on others, why not use a GNU tool specially designed to handle dependencies? Make the initscript into a makefile, and GNU Make should handle starting daemons quite nicely.

Re:as if

[robberbarron]

Uh, a Palm pilot doesn't boot when you turn it on. It merely comes out of sleep. The only time it boots is when you hit the reset button on the back. Then it takes about 5-10 seconds to boot.

However, there are a lot of embedded devices that do need to boot quickly. Automotive electronics like your radio, Nav-system, etc.. do boot up when you turn on the car, at least today they do.

Re:why is it ...

[nathanh]

... that when a company doesn't put its kernel changes out immediately, there's calls for hanging them for violating the GPL, but when a linux company optimizes boot-up routines in the kernel, nobody is asking when the patches are going to be making it into the mainline kernel?

Because the GPL only guarantees your right to source code if you first receive the modified binaries. You can't demand the source code "immediately" once the change has been made. FSM could conceivably keep this project in-house forever without releasing the source code. However as soon as they distribute binaries they must provide the source code.

hello! This doesn't affect you!

[GISGEOLOGYGEEK]

Won't someone here get a clue! This has nothing to do with a server or desktop computer! ... so give up all the bragging about how this beats windows, and all the boasting that you haven't booted in 4 years so it doesnt matter...

This doesn't affect you.

Re:I want the opposite

[bockman]

You would need something to preload the most heavy KDE shared libraries at boot time and keep them in memory.

Some slow-to-start program (e.g. galeon) can be started in 'daemon mode' to speed up the GUI start-up response (most of the initialization time is done by the daemon at boot time).
But it should not be difficult to make a program that just ldopen() a bunch of shared libraries and then stays alive (dunno if it will be swapped out, however).

If there is some KDE program that does not display anything but still uses most of the KDE libraries, it could be started as a service with a fake account, just to keep those libraries in memory.

Sort of depends the details...

[macshit]

This is a timed version of my kernel boot sequence on an RTE-V850E/ME2-CB board (a rather pokey processor -- 80MHz); the first column is seconds:

[ 0.002619 ] Linux version 2.4.21-uc0 (miles@mcspd15) (gcc version 2.9-v850ice-000414-nmit-20010327) #62 Wed Jul 16 16:03:57 JST 2003
[ 0.009299 ] On node 0 totalpages: 8192
[ 0.019597 ] zone(0): 8192 pages.
[ 0.030390 ] zone(1): 0 pages.
[ 0.030635 ] zone(2): 0 pages.
[ 0.030891 ] CPU: NEC V850E/ME2
[ 0.031065 ] Platform: Midas lab RTE-V850E/ME2-CB
[ 0.031322 ] Kernel command line:
[ 0.031869 ] 50 BogoMIPS (precomputed)
[ 0.067024 ] Memory: 24388K/32768K available (291K kernel code, 150K data)
[ 0.068884 ] Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.069639 ] Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.070279 ] Mount cache hash table entries: 512 (order: 0, 4096 bytes)
[ 0.071467 ] Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.072234 ] Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.073991 ] POSIX conformance testing by UNIFIX
[ 0.074414 ] Linux NET4.0 for Linux 2.4
[ 0.074663 ] Based upon Swansea University Computer Society NET3.039
[ 0.075648 ] Starting kswapd
[ 0.078020 ] Serial driver version 5.05c (2001-07-08) with no serial options enabled
[ 0.078538 ] ttyS00 at 0xfe08000 (irq = 90) is a 16550A
[ 0.079150 ] Blkmem copyright 1998,1999 D. Jeff Dionne
[ 0.079349 ] Blkmem copyright 1998 Kenneth Albanowski
[ 0.079544 ] Blkmem 1 disk images:
[ 0.079889 ] 0: 876000-FCE7FF [VIRTUAL 876000-FCE7FF] (RW)
[ 0.084282 ] VFS: Mounted root (romfs filesystem) readonly.
[ 0.085781 ] Freeing unused kernel memory: 20K freed

Whoo, 80ms!

Not that useful though (no network devices; network devices seem to take forever to start)...

Re:Congratulations

[vidarh]

"fast flash" is an oxymoron. Flash is slow slow slow. You most certainly don't want to execute code straight from flash unless your system is ridiculously slow anyway.

Just copying a kernel or a suspend image from flash will give a quite noticeable delay.

And take a look at swsusp - restarting a suspended kernel is NOT trivial. You need to reinitialise hardware, some of which may not allow you to read back their state (graphics cards being a common culprit) so that you need to know what state they were in on suspend.

Uhhh, milli Siemens?

[sdijkstra]

"milli Siemens"?

Is that some sort of miniturized German electronics manufacturer?

I always thought that mS stood for "milli Sievert", a unit for ionizing radiation...

Suspend vs Hibernate

[arete]

First of all, most people in this thread. are talking about suspend/standby, not hibernate. Hibernate is a no-power mode ('cept the clock) which writes all RAM data to disk, while standby is a low-power mode (no display, disk, etc.) that just basically waits. Hibernate is historically somewhat less reliable, although either will destroy open network connections. Both modes work quite well in Win2k+, although I'd certainly be scared in 95/98/ME.

On most laptops I've seen, you can set the bios to send standby, hibernate, or nothing to the OS when you close the case. Any effect can be used with the case open by selecting it from the Start-> Shutdown menu.

On my 233Mhz Thinkpad 600 (which is a wonderful if aged machine, but which isn't technically supported by Windows 2000 which is running it) I have case-close mapped to standby and the power-button mapped to hibernate. I also have autohibernate on low battery. So if I close it it goes to standby and from standby it'll shutdown if it gets in danger of running out of power to stay going. (Standby does _not_ last indefinitely on battery)

I've had Windows 2000 fail to recover on hibernate, but not very often and that machine had other issues. I've _thought_ standby was failing on this laptop because the response time to the wakeup button-press varies and isn't particularly fast. It's occasionally woken up without the mouse, but the mouse is finicky to start with (again, W2k doesn't properly support the onboard mouse) Sleeping and waking again has always fixed the problem, all applications still running.

All of that said, however, I certainly recommend saving everything important before sleeping, hibernating, changing power sources, or transporting the machine (even in case-closed but staying on mode) All of those things are somewhat more risky than doing nothing, but less risky than some applications.

MacOS X

[arete]

MacOS X is by far the best desktop environment _I've_ ever used, and it's far better than XP. It does tend to be more expensive, of course.

It does almost everything you want it to, and it does it automatically, and they're constantly building new features in smooth ways.

It also has one of the largest available software bases around: It runs MacOSX software, MacOS7/8/9 software, linux/BSD software compiled for PPC (X11 isn't installed by default, but the OpenOffice.org installer smoothly includes it, for instance, and it's on the OSX CD) and has an available emulator (VPC) that allows you to run x86 in a window, including Windows or Linux.

Even they aren't perfect, but they're closer than anybody else. Oh, and "Mail" rocks, hard.