Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Software Tweak Makes Linux Boot In Under 200 ms 385

Posted by timothy from the ymwv dept.
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.
This discussion has been archived. No new comments can be posted.

Software Tweak Makes Linux Boot In Under 200 ms More

Software Tweak Makes Linux Boot In Under 200 ms

Comments Filter:

  • Only for embedded devices (Score:5, Informative)

    by Professor_Quail ( 610443 ) on Monday September 29, 2003 @08:21PM (#7090297) Homepage
    This isn't for desktop linux, only for embedded devices.

    • NOT Only for embedded devices RTFA (Score:2, Informative)

      by Anonymous Coward
      RTFA
      "Yodaiken said the new fast boot technology also supports many Intel x86 boards"
    • yeah, I saw that too.. Slightly off topic, but what's the fastest boot time you can get with a 300mhz laptop? I have a compaq armada currently running Win 98, and if Linux can boot up faster than win 98 (I disabled a lot of stuff that autolaunches, like virus scanners, firewall, etc) I can use the laptop to take notes in lecture.

      • Re:Only for embedded devices (Score:5, Funny)

        by ihopMaintenance ( 711275 ) on Monday September 29, 2003 @10:00PM (#7091009)
        I disabled a lot of stuff that autolaunches, like virus scanners, firewall, etc

        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.
    • The article says this work was done to improve the boot time of embedded devices, but I don't see anywhere why these changes couldn't be applied to any other computers running linux.

      • Re:Only for embedded devices (Score:5, Interesting)

        by HidingMyName ( 669183 ) on Monday September 29, 2003 @08:46PM (#7090510)
        I'm not privy to his techniques, but he may be hardwiring the compiled kernel for the target architecture to get more speed (recall that when programming, using early binding times trade off flexibility for speed). Yodaiken's a smart guy, so I may not have guessed his tricks.

        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.

    • ahh... makes much more sense...

      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)

    by commodoresloat ( 172735 ) on Monday September 29, 2003 @08:22PM (#7090304)
    any linux user wants to sacrifice their uptime to boot faster

  • incredible (Score:5, Informative)

    by alienhazard ( 660628 ) on Monday September 29, 2003 @08:23PM (#7090310)
    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.

  • They (re)invented XIP? (Score:3, Informative)

    by Dancin_Santa ( 265275 ) <DancinSanta@gmail.com> on Monday September 29, 2003 @08:24PM (#7090322) Journal
    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 (Score:5, Informative)

    by Ankh ( 19084 ) * on Monday September 29, 2003 @08:24PM (#7090324) Homepage
    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:kernel boot != complete system initialization (Score:5, Insightful)

      by Weaselmancer ( 533834 ) on Monday September 29, 2003 @08:37PM (#7090441)

      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)

      by Kashif Shaikh ( 575991 ) on Monday September 29, 2003 @10:07PM (#7091054)
      ...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;)

  • Slightly off topic but about *nix boot times (Score:3, Insightful)

    by Zelet ( 515452 ) on Monday September 29, 2003 @08:26PM (#7090343) Journal
    I have noticed that *nix boot times are noticibly longer than Windows XP boot times. I have never been able to figure out why this is - does anybody know?

    Thanks
    John

    • Re:Slightly off topic but about *nix boot times (Score:5, Informative)

      by gordyf ( 23004 ) on Monday September 29, 2003 @08:28PM (#7090358)
      Linux starts its services before it brings up the password prompt. Windows loads, displays the login prompt and continues starting services in the background.
      • Could Linux theoretically do this? If so - why doesn't it?
        • There are some projects which are trying to modify rc scripts to boot on background (now it's sequential - after one is completely started up next one is started). Problem is dependency but I've seen some quite good solution to this. But I don't remember the name any more :-(
        • Could Linux theoretically do this? If so - why doesn't it?

          cuz you want you want your server to be useful without having to log in

        • With a few exceptions (such as starting the network) Linux services could be started in arbitrary parrellel order. I think that someone, somewhere, has dones this. The question is, would you really want it?

          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)

          by phorm ( 591458 )
          Try instead setting an "automatic login" to a default user... count your time period up to the point where everything has stopped loading (your hard-drive will stop ticking, heh) and all your tray icons etc etc are in place. Significant difference between that and booting just to the initial user-selection/login screen

          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.
          • The significant difference between booting to login-screen and booting to the desktop comes from all the apps set to load for a user, such as aim, icq, msn, some virus scanners (most should load as a service), volume control apps, video driver helpers, not to mention explorer itself! Ever used a person's computer and seen 95371 systray apps? They (well, most) load on login, not on boot.
          • Part of the windows problem seems to be that startup applications and services all try and execute in parallel, thus thrashing the hell out of the drive and slowing the machine a whole lot.

            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.
        • Yes, Windows does a login prompt earlier in its boot sequence than Linux usually does, but just because you've typed in your login and password doesn't mean you've got a usable system, especially on Windows. After you do that, it spends a while loading lots of System Tray applications, running whatever it runs to get pretty icons on your desktop, and also running whatever equivalents to .profile are set up on your network login as well as running your Startup folder apps. Moving the request for a password
        • Yes, GNU/Linux could theoretically do this. But we're mostly missing/off the point of the article:

          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).
      • This is a great example of where nit picking "Linux the kernel" vs "Linux the operating system" is right on.

        "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
    • Windows XP are usually nothing more then OS+GUI. But Linux usually boots all kind of services also.
    • Dunno, but at least it's consistant. Unlike windows where the boot time seems to double every couple months, even when you keep unused apps uninstalled, defrag and run registry cleaners and spyware detectors often and kill all unneeded services...

      I'll be damned if I can figure out how to fix that without doing a monthly reinstall...
    • Windows XP doesn't finish loading everything before you actually see the screen. Not sure about your system, but my XP get me to the welcome screen in maybe 15 second... the welcome screen then sits there for about another 5 seconds, then I finally get my login... after logging in it continue to load a lot of my device drivers which freeze the system up (not completely but make it slow to the point I can't use it) for about another 30 seconds. You could probably modify init to provide you with a login pro
      • One difference is that you may still be running Linux on that "cutting edge when you bought it" P2-233, but you're unlikely to be running XP on anything less than 800 MHz or so, plus you've got a bigger faster disk drive and more memory. Sure, you could do an apples-to-apples comparison, but the big reason that Win2k Pro boots so fast on my new work laptop is that it's an 1100MHz box. (Another reason is that Suspend/Resume finally works reliably enough that I don't need to reboot more than every week or s

      • 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)

      by MerlynEmrys67 ( 583469 ) on Monday September 29, 2003 @08:39PM (#7090450)
      Windows does some very intersting things with both optimizing the location of sectors on the hard drive and loading drivers

      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

      • 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. Of course, you could also arrange so that the module is not linked to the kernel but just contained in the kernel image (and linked at runtime, as if it had just been loaded into memory off of the disk), at which point it's "mere aggregation" and permitted for distribution by the GPL.

        For that matter, if you're exclusively an end u

        • 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

    • There are probably a lot of services starting that you don't need. KDE has a good SysV Init editor you can use that has an interface kind of like the Windows service editor. Just get rid of all the stuff you don't need, and you should find that your bootup time is reduced drastically.

      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

    • I have noticed that *nix boot times are noticibly longer than Windows XP boot times. I have never been able to figure out why this is - does anybody know?

      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.

      • I just booted my 500MHz laptop in 20 seconds in Linux, that's from GRUB to login. Booting Windows 2000 on it takes about 80 seconds from 'press F8' to 'Login'

        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.
      • There is still a world of differance. WinXP is fully usefull for me in about 30-35seconds from the time i hit the power button. This is on any of my computers. Linux for me and any other computer I have seen it on is in the minutes range to boot. I'm sure people have it boot fast, but that in no way seams to be normal. Also if your using some sort of tweak to get faster boots that doesn't count either since when you are compairing you have to work in terms of out of the box. Since if you tell a person l
    • In my case just now, "/dev/hdb1 has gone 180 days without being checked; check forced". But normally my machine (which only starts things I want) takes less time than it takes Windows XP to wake up if you let it go to sleep (I don't think I've ever seen Windows XP boot).

      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.

  • Seems pretty simple to me (Score:5, Interesting)

    by MerlynEmrys67 ( 583469 ) on Monday September 29, 2003 @08:29PM (#7090367)
    Rather than keeping a kernel that gets loaded at boot time...

    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)

      by seanadams.com ( 463190 ) * on Monday September 29, 2003 @08:53PM (#7090561) Homepage
      Go RTFA - several points: You don't just simply "load an image into memory" and have a running system. This is why properly supporting APM is difficult on any machine. All your hardware needs to be reinitialized. Network connections need to be reestablished (getting IP and so on), file systems need to be remounted, there are all kinds of timer-driven things that need special handling, and so on and so forth.

      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).
      • I did read TFA - And guess what - you have a few edge cases to consider... But reinitializing hardware in a running system is rather easy - especially in a closed system environment. Would this work for the desktop - probably not with a rearchitecture of the driver interfaces... but nothing stops it. I mean what is the difference between this and the Windows suspend feature, especially when you are using Flash to load your running image off of.
      • Something that's been bugging me for years is that computers and OS's that's capable of saving state to disk and then turn off won't let me create a state-image of my newly booted environment and then always load it at power on instead. (Wah! That was a long one.)
        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

  • Booting Linux Faster through Blocking (Score:5, Informative)

    by Eponymous Cowboy ( 706996 ) on Monday September 29, 2003 @08:32PM (#7090400)
    Although this article refers to embedded systems, the earlier Booting Linux Faster [slashdot.org] article contained an overlooked post by TornSheetMetal, who had a great idea [slashdot.org] 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 [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.
    • Hehehehehehe. We used to use a trick very similar on the Amiga way back when. "LoadWB" in your startup-sequence would actually load and display the Amiga WorkBench (similar to Finder, Explorer, whatever).

      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)

      by targo ( 409974 ) <targo_t.hotmail@com> on Tuesday September 30, 2003 @01:37AM (#7091417) Homepage
      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.
    • 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 (Score:5, Informative)

        by Anonymous Coward on Tuesday September 30, 2003 @02:02AM (#7091529)
        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.)

      • make -j (Score:3, Interesting)

        by Julian Morrison ( 5575 )
        Seeks storms aren't inevitable doing stuff in parrallel. The Kernel's quite capable of handling a modest amount of simultaneous disk accessing. It's only doing too much at once in parralel that leads to "thrashing".

        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)

    by pesc ( 147035 ) on Monday September 29, 2003 @08:43PM (#7090486)
    But what does electrical conductance [wikipedia.org] have to do with boot times? 100 mS is 100 milliSiemens [nist.gov]. Milliseconds is abbreviated ms.
  • check out www.linuxbios.org. Too bad I don't have any motherboards with a supported BIOS. It sounds way cool. Kind of like turning a legacy PC into a modern embedded device. heh

  • They removed the offending code: (Score:3, Funny)

    by cybermace5 ( 446439 ) <g.ryan@macetech.com> on Monday September 29, 2003 @08:51PM (#7090545) Homepage Journal
    // Code to make Linux startup look like it's doing something
    // Insert in a few hundred random places
    long foo = 0;
    while (foo < 10000000)
    {
    foo++;
    }

  • Misleading... (Score:2, Insightful)

    by DroopyStonx ( 683090 )
    What a misleading article.

    Could've at least put non x86 or embedded device in the title.

  • Would make a great commercial (Score:3, Funny)

    by niko9 ( 315647 ) on Monday September 29, 2003 @08:55PM (#7090579)
    Scene one, Act One

    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)

    by sl0ppy ( 454532 ) on Monday September 29, 2003 @08:58PM (#7090593)
    ... 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?

    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)

      by seanadams.com ( 463190 ) * on Monday September 29, 2003 @09:12PM (#7090686) Homepage
      They only have to distribute their source to whomever they distribute a binary, if and when they do so. Under the GPL you do not bear the burden of publishing, distributing, and supporting source changes that you made for your own use, or changes which you have not yet distributed.

      • Re:why is it ... (Score:2, Insightful)

        by sl0ppy ( 454532 )
        They only have to distribute their source to whomever they distribute a binary

        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?
        • and this is different than linksys how?

          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:3, Informative)

      by nathanh ( 1214 )

      ... 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

  • I had a professor tell us this story of one of his previous coworkers:

    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)

    by monkeyboy87 ( 619098 )
    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.

  • I can boot up DR-DOS in an emulator in a few milliseconds, not 200 of 'em! And keep in mind, the emulator just adds overhead. If I somehow managed to install DR-DOS on my tripped-out Athlon XP 3000+ system, it'd boot in even LESS time!
  • Comment removed based on user account deletion

  • The Power Companies (Score:3, Funny)

    by Kujah ( 630784 ) on Monday September 29, 2003 @10:08PM (#7091065) Homepage
    It's too bad the damn power companies havn't spent some time improving their boot times... it took them like a week to restore my power *grumble*

  • Sort of depends the details... (Score:3, Informative)

    by macshit ( 157376 ) <snogglethorpe@NOsPAM.gmail.com> on Tuesday September 30, 2003 @03:21AM (#7091763) Homepage
    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)...

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close