Software Tweak Makes Linux Boot In Under 200 ms 385
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.
Only for embedded devices (Score:5, Informative)
NOT Only for embedded devices RTFA (Score:2, Informative)
"Yodaiken said the new fast boot technology also supports many Intel x86 boards"
Re:NOT Only for embedded devices RTFA (Score:4, Informative)
Re:NOT Only for embedded devices RTFA (Score:5, Informative)
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.
Re:Only for embedded devices (Score:2, Interesting)
Re:Only for embedded devices (Score:5, Funny)
Good idea. Virus scanners and firewalls use WAY too much overhead. Heck I used to run them and they interfered with my screen savers and stuff. Who needs em.
Re:Only for embedded devices (Score:3, Interesting)
I can't even measure it now on a StrongARM/202MHz, also consider the newest RiscOS powered computer : Iyonix [iyonix.com] (Xscale/600MHz)...
Re:Only for embedded devices (Score:3, Funny)
The last time we tried to suspend the Armada, all our ships sank.
Suspend vs Hibernate (Score:3, Informative)
On most laptops I've seen, you can set the bios to send sta
Re:Only for embedded devices (Score:3, Insightful)
Re:Only for embedded devices (Score:5, Interesting)
Embedded devices may not need to do things like hardware discovery, plug and play configuration, etc. since their hardware configuration may be constant (so this stuff could be compiled into the kernel). Additionally, booting the kernel is different than doing various daemon startups and file system initializations, network configuration, etc. that one typically wants for non-desktop devices.
Comment removed (Score:5, Informative)
Re:Only for embedded devices (Score:4, Interesting)
Oh, come on now... I'm no MS apologist, but Win98's power management support was notoriously bug infested. (I know - I was Program Manager for Dell's laptops when it was introduced!)
Comparing this to W2K or XP is like comparing DOS to VMS. There are similarities, but they are only superficial. Power managment in XP is flawless, and implemented FAR better than in even the latest mainstream Linux distros, which always seem to be two years behind the times in hardware support. (
Sadly, PM has never been very good in Linux, I think mostly because of the anti-MS bias - If you don't hang out at the Windows Hardware Developer Conference, how are you going to know enough about the PCxx standards (which, like it or not, *define* what a PC is and how it works) to write good PM code? Answer: You can't!
I have to say though, despite the fact that I really dislike some of Microsoft's business practices, I recently upgraded my primary desktop to XP, and it's *by far* the best desktop environment I've ever used (after expunging IE/OE for Mozilla). Like it or not, XP is a real OS, and particularly as a desktop (still 100% BSD/Linux for servers), it's the most stable and functional setup I've seen. (And this is with the low-budget XP Home, since I didn't really need the few extra features of Pro they charge another $100+ for.)
If I sound surprised, it's because I am - W2K was the first "real OS" from Redmond, and XP is a much bigger improvement on it than I expected. Now if they could just secure it, and would quit intentionally breaking things... (like for instance *every* (older) version of Visio - Grrrr)
MacOS X (Score:3, Informative)
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
Re:Only for embedded devices (Score:2)
I had something resembling
"My BIOS takes at least 10-20 times that, how can my OS speed that up..."
On topic, it is very cool to have an operating system that can start that quickly -- assuming stability, which is essential in embedded stuff (what happens when your Microwave has a kernel panic while cooking, for example)
Embedded devices really should start very fast, so boot time is really important. That said, this thing about 100ms being available eventually doesn't matte
as if (Score:5, Funny)
Which prompts the question: (Score:2)
Re:Which prompts the question: (Score:2)
#!/bin/sh
echo "42 years!"
There ya go.
Re:Which prompts the question: (Score:5, Funny)
Re:Which prompts the question: (Score:3, Funny)
5:33pm up 22342352324 days, 6:28, 2124315623 users, load average: 0.01, 0.00, 0.00
The uber-server.
Re:as if (Score:3, Insightful)
Re:as if (Score:4, Informative)
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:as if (Score:4, Insightful)
Re:Why bother anyway? (Score:3, Insightful)
incredible (Score:5, Informative)
They (re)invented XIP? (Score:3, Informative)
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 (Score:5, Informative)
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:kernel boot != complete system initialization (Score:5, Insightful)
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.
True, but this is still great.
The article says, "less than 200 milliseconds (mS) from power-up to application code startup." The thing that makes this great is that not every device is going to go through the entire *nix init sequence.
How about a device like a Linux embedded router, or something like that? Just a kernel running and that's all. Or how about a dashboard mp3 player that only needs to run one application?
This makes Linux much more like customized firmware, and there are plenty of places to use that.
Granted, this'll be great when it makes it to the desktop, too. =)
Weaselmancer
And everyone knows... (Score:5, Informative)
In other words, it loads everything AFTER you login, no joke;)
Slightly off topic but about *nix boot times (Score:3, Insightful)
Thanks
John
Re:Slightly off topic but about *nix boot times (Score:5, Informative)
Re:Slightly off topic but about *nix boot times (Score:2)
Re:Slightly off topic but about *nix boot times (Score:2)
Re:Slightly off topic but about *nix boot times (Score:2)
cuz you want you want your server to be useful without having to log in
Re:Slightly off topic but about *nix boot times (Score:2)
On windows, it boots up and quickly presents the creen in a finished-looking way, but the daemons launching take up so much CPU that the widgets are unresponsive. With intermittant splash screens disrupting focus. I've gotten in the habit of listening carefully for the hard drive to stop growling, an
With XP, outer rim. (Score:3, Interesting)
For linux, you can try a few hard-disk tricks. Also, your filesystem might be slow... try reiser as it seems to run quite nicely. For swap partitions, put them at the end of your hard disk.
Re:With XP, outer rim. (Score:2)
Re:With XP, outer rim. (Score:2)
Why not force (or allow the user to set) a limit on the number of startup applications that execute simultaneously to avoid thrashing the drive and making the startup sluggish.
Login Prompt vs. Useful System (Score:2)
Re:Slightly off topic but about *nix boot times (Score:3, Interesting)
The article is talking about Linux boot times. As they mention, Linux boots in 5 seconds on most cases (embedded or on your system) from the boot loader to kernel initialization is quite fast.
The kernel (Linux) then starts loading application code (network services, security daemons, x windows, etc).
To your question: Parallelizing services initialization can dramatically improve time to log on screen (LOS).
Linux != init.d (Score:2)
"Linux" does NOT "start its services before it brings up the password prompt". Redhat does that. SuSE does that. That is a limitation of the init.d system used by some distributions, and has nothing to do with this work that FSMLabs has announced.
If you slim down a 2.4.x kernel a bit and run it with a minimal setup like BusyBox it is very easy to get a login prompt within 5 seconds of the BIOS sc
Re:Slightly off topic but about *nix boot times (Score:2)
Re:Slightly off topic but about *nix boot times (Score:2)
Re:Slightly off topic but about *nix boot times (Score:2)
I'll be damned if I can figure out how to fix that without doing a monthly reinstall...
Re:Slightly off topic but about *nix boot times (Score:3, Insightful)
XP = Newer, Faster Hardware (Score:2)
Re:Slightly off topic but about *nix boot times (Score:2)
My windows xp was like the above with 512MB of ram. When I upgraded to a gigabyte of ram, my boot time was cut in half, and it was ready for me to log in just as soon as the screen appeared. I loaded a bunch of crap which starts up taskbar icons and makes the system effectively unusable for about 15 seconds while all that crap starts up, but that's my own fault. Most widnows users don't feel a need to load three IMs, waste, a livejournal post agent, an antivirus program, a transparent window manager, a rai
Another Windows optimization (Score:5, Interesting)
For the hard drive - rather than put executables down 1-n on the hard drive - Windows (for many years) figures out the load order of sectors of the executable - and fragments them across the sectors in that order - net effect +10-50% load time boost from using the hard drive effectively
For drivers - there is this really interesting way that windows is now initializing driver loading by putting them into the kernel image itself... Kind of like taking modules in Linux - and rather than having the overhead of loading the module each time you boot - insert it into the kernel - and letting the kernel load (with a "static" module in now) - This one is a little trickier to put into a Linux environment... what does the GPL say if I have a loadable module - yet the kernel now statically links it in as an optimization... I don't even want to go there
Re:Another Windows optimization (Score:2)
For that matter, if you're exclusively an end u
Re:Another Windows optimization (Score:2)
If you have a binary module and you statically link it to the kernel, you can't distribute the result. In this situation, though, you don't want to distribute it, so you're fine.
In the case of developers of embedded systems, they generally do want to distribute the result, inside a device.
However, in most embedded devices, the time required to load a module from media isn't relevant, since all of the code is probably in flash RAM anyway, so they just run the code from where it is. As a result, the cos
Re:Slightly off topic but about *nix boot times (Score:2)
Or if you want to start a lot of services, you could do it the way I do it. I've got a script I run as soon as I log in to start most services. While that's initializing all that stuff, I go to tty2 and start my X session. Thi
Re:Slightly off topic but about *nix boot times (Score:2)
Sure. Very simple.
The number of services normally started up in someone's standard Linux install are many more. My friends and I noticed this actually, and once making the services similiar to a Windows boot, I was able to boot quicker on my 1700+ laptop than my friend's 2.0ghz Centrino, which was running XP.
Not for me. (Score:2)
Also, when the linux box says I'm good to login, it is, everything is already loaded. The windows box sits there for a while AFTER I login to sort itself out and let me to the desktop. I think it's because *nix INIT process wants to load services first and let users in later, Windows is the other way around.
Re:Slightly off topic but about *nix boot times (Score:2)
Re:Slightly off topic but about *nix boot times (Score:2)
Many distributions are slow because they check for new hardware, involving probing for a ton of stuff that requires I/O bus cycles. But if you happen to have Oracle, that's what will take all the time.
Re:Slightly off topic but about *nix boot times (Score:2)
Re:Summary of preceding posts (Score:2)
While I am not sure about Linus's father, I am quite certain that Linus's wife could
Seems pretty simple to me (Score:5, Interesting)
Keep the image that the kernel creates AFTER boot - simply load that into memory and restart.
That said - you still need the long boot the first time, and after any hardware changes. Also, I am guessing to get it into the sub second range - hard drives are right out as well - and all of the silly boot managers. But for an embedded device - who cares
No, it is not that simple at all. (Score:5, Interesting)
What these guys are doing is optimizing for embedded systems - where the kernel is hardwired for exactly the same hardware every time. You don't need to probe, and you don't need to guess what state the hardware is in - it's a closed system and it's the same at every power-on. Furthermore there are all kinds of things you can initialize simultaneously when you can optimimize for a deterministic environment - if your video system wants a moment to do a POST, you can spend that time initializing a network interface, for example.
Also, the definition of "boot time" for this dicussion is the time until the first application-level code runs. That's something like only 1/3 to 1/2 of the boot time for a typical linux server or desktop that you're thinking of. Most of the time is spent bringing up userland services and loading the graphical environment. There's a big savings on big workstation in flushing RAM to disk, but not so much for small embedded systems, where application state is very minimal (eg a Tivo, or a wireless router).
Re:No, it is not that simple at all. - but it is (Score:2)
Re:No, it is not that simple at all. (Score:2)
I've been wondering about this since I got my first IBM Thinkpad around 1998.
It could hibernate to disk and then power off.
This was done to a separate partition and was independent of OS.
To "boot" again took the time to read 24 MB from the harddriv
Re:Congratulations (Score:2)
Then you go off and talk about Hibernate. Suspend simply stops the CPU and keeps the RAM hot... Allowing the CPU to come back where it left off. Hibernate actually writes it off to hard drive.
Now in an embedded environment - I can have a HOT OS on a fast flash that I can execute from. Why do I store the kernel there - just store a suspended kernel
Re:Congratulations (Score:3, Informative)
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 i
Re:Seems pretty simple to me (Score:2)
The joys of hot plugging and module insertion... Driver init code actually doesn't take much. Perform a hot swap event on the hardware when you restore... probably where most of the 200 mS gets spent
Booting Linux Faster through Blocking (Score:5, Informative)
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 [cr.yp.to] and svok [cr.yp.to] (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.
Re:Booting Linux Faster through Blocking (Score:2)
You would do your basic initialization (establish your path, your assigns, etc.) then run "LoadWB" and *then* load all your other crap.
End result....System would boot and be "useable" in a couple of seconds, even on an 8Mhz system.
Re:Booting Linux Faster through Blocking (Score:5, Informative)
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 (Score:3, Informative)
Re:Booting Linux Faster through Blocking (Score:5, Informative)
make -j (Score:3, Interesting)
Perhaps a solution would be the equivalent to "make -j", where you can tune how many simultaneous things to run. In fact "make" is a good model for this whole approach, since the control mechanism will also need to do dependency-blocking.
Other refinements that occur to me:
- Things could be mar
100 mS? (Score:3, Interesting)
And for the desktop, there is always LinuxBIOS (Score:2, Interesting)
They removed the offending code: (Score:3, Funny)
// Insert in a few hundred random places
long foo = 0;
while (foo < 10000000)
{
foo++;
}
Re:They removed the offending code: (Score:3, Funny)
Re:They removed the offending code: (Score:2)
Since foo isn't volatile, the compiler will notice that code does nothing and will remove it
Misleading... (Score:2, Insightful)
Could've at least put non x86 or embedded device in the title.
Would make a great commercial (Score:3, Funny)
Adrian Lamo in a orange prison jump suit conferencing wit his attorney.
Ring Ring
Attorney: Hold on Adrian, I have to take this call. (talking into cellphone) Yeah.. ok... Great! ok..Thanks!
Great news Adrian!
Adrian: (curious/happy): What?!
Attorney: I just saved 4.8 seconds on my Linux boot time with FSMLabs!
Adrian:
why is it ... (Score:4, Insightful)
from the looks of the article, FSMLabs has been basically profiling the kernel, looking for sticking points, and optimizing them.
why wouldn't at least some of this work be contributed back to the mainline kernel? it is modifications on a GPL'd kernel, after all.
Re:why is it ... (Score:5, Insightful)
Re:why is it ... (Score:2, Insightful)
and this is different than linksys how?
this isn't meant to be a troll, but i'm really not seeing how this is different.
FSMLabs sells RTLinux, a real-time version of linux. i'm sure that they are doing their duty and distributing the source of the RTLinux kernel. wouldn't their additions to the kernel become GPL, and be able to be integrated into the main-line kernel?
Re:why is it ... (Score:2)
When I buy a linksys router I am gettting linux binaries running on the system.
FSMLabs sells RTLinux, a real-time version of linux. i'm sure that they are doing their duty and distributing the source of the RTLinux kernel. wouldn't their additions to the kernel become GPL, and be able to be integrated into the main-line kernel?
At this point there is no reason to doubt that when they release these changes in the form of a product, we'll get source.
Re:why is it ... (Score:2)
Exactly what? Do you agree with me or are you just very confused?
I would suggest that you read the GPL. It makes no distinction between software for PCs versus software for embedded systems. It just says you have to ditribute the source to whomever you distribute a binary. What is confusing about that?
Re:why is it ... (Score:3, Informative)
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
Good news. Now my software can be more buggy. (Score:5, Funny)
She had designed and implemented a simple service on top of unix which was accessed by a moderate number of users. When the time to put it into production came, she looked at her remaining few crashing bugs and determined to put in a monitoring loop that would reboot the server if such a situation happened. She also determined that no data loss would occur.
Why did she do this workaround, and how did she determine what bugs she could leave in?
She had a 5 digit company phone extension. She determined that someone could call her, if she let her phone ring twice, in a short period of time. During this time the server would have finished rebooting and start serving again. She could answer the call and simply say, "Try it again", whereupon the user would find that his operation worked this time.
So remember - if your server can reboot itself (and does so automatically and safely) before they can finish dialing tech support, you have no worries!
-Adam
WTF?!?! (Score:2, Informative)
oh wait. these are embbeded systems for things security, monitoring equipment etc. yeah i can see reboot times being critical.
200ms?! That's forever!! (Score:2)
Re: (Score:2)
The Power Companies (Score:3, Funny)
Sort of depends the details... (Score:3, Informative)
[ 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:Time To Abandon Windows? (Score:2)
Re:Time To Abandon Windows? (Score:2)
But do you have a functioning SYSTEM?
XP-login != fully-booted
Re:Time To Abandon Windows? (Score:2)
Are you making the HUGE mistake of shutting down and rebooting the system when you hit the power button ?
What a waste - hibernate works well on laptops - suspend (which is even faster) works well for desktops
Re:Oh well (Score:2)
ps. the sticker is 4000 not 40000.
Re:200 mS? (Score:2)
Oh, Timothy and the anonymous story submitter meant milliseconds, ms.
Why is it that not even alleged nerds can use units and prefixes properly these days? Measuring disk space in "mb", CPUs operate at clock frequencies of a certain number of "mhz", and their modems are of the "56 KBPS" kind...
Or is "S" another US-centric medieval unit, for measuring time?
Re:200 mS? (Score:5, Funny)
Actually, the "S" unit refers to the Imperial Second, which is defined as the interval of time between now... and now.
I'll be impressed (Score:3, Funny)
Re:Wait a second, or rather, 200ms (Score:5, Funny)
Linux doesn't crash. It "creatively parks".
Re:Wait a second, or rather, 200ms (Score:2)
Yeah! You sure showed him you rocket scient.. I mean, aerospace propulsion engineer!
Re:Wait a second, or rather, 200ms (Score:2)
Re:I want the opposite (Score:3, Informative)
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 anythi