Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Technology

Booting A PIII System In .8 Seconds 353

Posted by timothy from the no-more-beauty-sleep-time dept.
gizmo_mathboy writes: "General Software has announced the fastest BIOS boot time on record. The embedded system was clocked at 0.8 seconds from system power-on to transfer of control to LILO. This was on an Intel SOYO motherboard (440BX chipset) running a PIII 400. I think the quote of the article is: 'This Embedded BIOS quick-boot operation allows the device to restart and resume operations well within three seconds -- the maximum amount of downtime allowed per year for a device that must support "seven nines" or 99.99999 percent uptime.'"
This discussion has been archived. No new comments can be posted.

Booting A PIII System In .8 Seconds More

Booting A PIII System In .8 Seconds

Comments Filter:
  • Once i add some scsi , network, raid cards I can slow it down again :o)
  • Anything that can be done to help those online gamers deal with crappy, untested game clients that crash their computers should help Electronic Art's, Sony's and other MMORPG game companies profit margins. I can see the recession turning around already, especially with gamers able to reboot so quickly.

  • that is fast but... (Score:5, Funny)

    by mandria ( 442627 ) on Monday August 27, 2001 @10:38AM (#2221205)
    sometimes i would like to have a sec more to press the delete button to get into the bios and change a few settings.
    • This is designed for embedded devices, not your home computer. Therefore, you'd likely be hard pressed to find a delete button (or any other one for that matter) that would let you into the BIOS.
    • sometimes i would like to have a sec more to press the delete button to get into the bios and change a few settings.

      This is going to blow your mind, but you don't actually have to wait until you see the text to press DEL!

      doink
  • You can find the BIOS they used here [gensw.com]. It has to be custom-tuned, but this kit includes the code itself, so you can build the BIOS yourself. They basically disabled most of the checks and auto-configure options; no disk seeks (reasonable enough in a highly reliable system), only check the first word of every 1K memory block, no auto-configure of IDE, etc.

    I've been waiting for something like this for a while! My car MP3 player takes too long to boot up... can't wait to get my hands on this. No mention of cost, but I've sent an e-mail to their contact link and will reply to this message with price if/when they get back to me.

    • how long does your car mp3 player take to boot up that is due to POST time??
      • It's VERY random... between 8 and 15 seconds... one of these days, I'll get a website up about it... but its running on an old PII, Slackware 5.4 (a good release that supports all the hardware I need and none that I don't, that I'm very familiar with kernel hacking in)... The LILO to music time is about 3 seconds (due mostly to compiling the kernel with only the modules I need and tuning the startup scripts), but it takes 8 to 15 seconds to get there...
        • What if you installed a sort of "sleep" mode, or "suspend" mode? What type of hardware setup are you using anyways? I just mounted a laptop in my front (removable) with a GPS unit in the pcmcia slot and kept it always-on basically, sleep mode and plugged in inside. The GPS is really cool, too bad I don't have any decent mapping software to with it (I live in Canada).

        • Mine boots up at a nice consistent 12 seconds. I'm running a Fic VA 503+ and a POS Cyrix space heater chip (it was cheap). You can gain a little time by sticking the kernel right in the boot sector, but you've gotta strip it down enough to make it fit. Did you turn off all of the BIOS auto-detect crap you could?



          You might look into the Linux BIOS project at http://www.linuxbios.org/ [linuxbios.org] as well. I'm sure it's mentioned farther down in teh comments here, but I haven't read that far yet. ;)

  • There was no PIII/400 (Score:2, Informative)

    by sootman ( 158191 )
    Was that supposed to be 1400 MHz PIII, or PII/400, or some other speed of PIII? (Or was it a Celeron, or 286?) I checked the article, they got it wrong there-- not /.'s fault.

  • It's about time... (Score:4, Funny)

    by Anonymous Coward on Monday August 27, 2001 @10:42AM (#2221227)
    It's taken 20 years, but they finally got a system
    that can boot faster than a TRS-80.
  • Everyone doing server stuff should drop thewir x86 boxes and get a Sun right now!


    Seriously


    The SPARC architecture does not use a BIOS with REAL mode drivers for booting. It has protected (or whatever it is in non-x86 parlance) mode drivers built right into the firmware. On x86, the BIOS contains Real mode drivers, THis was fine for operatings systems like DOS and Win 3.1. However, modern OSs (Windows, Linux, etc) need protected mode drivers. BY placing these right in the fimware Sun is able to smoke x86 performancewise ALWAYS. I thin its time to ditch our legacy DOS hardware and start getting x86 machines with protected mode BIOS drivers. Anyone with more technical information, please comment.

    • It's a bootstrap. It's going to have different drivers from the operating system anyhow, so what does it matter if they are real mode, protected mode or a-la-mode. There is no significant speed difference between real and protected mode anyhow (it's running on the same CPU) so I think your point here is way off the mark.

      I really don't think everyone is going to drop x86 and by SPARC because of boot times. x86 has always blown SPARC out of the water in price/performance anyhow, and what am I going to do with all my x86 software if I move?

    • Re:Get a "REAL" Computer (Score:4, Interesting)

      by marxmarv ( 30295 ) on Monday August 27, 2001 @12:11PM (#2221594) Homepage
      Anyone with more technical information, please comment.
      Considering that almost all your information is wrong, I'll be happy to correct it as best I can.

      The SPARC architecture does not use a BIOS with REAL mode drivers for booting.
      The SPARC doesn't have or need real mode.

      It has protected (or whatever it is in non-x86 parlance) mode drivers built right into the firmware.
      No it doesn't. It has drivers written mostly in Forth bytecode, just capable enough to bootstrap the OS. See also: OpenBoot.

      However, modern OSs (Windows, Linux, etc) need protected mode drivers
      Drivers do not operate in a vacuum. Among other things, they need to initialize/uninitialize themselves, manage (allocate/free, map/unmap, lock/unlock) memory, cooperate with other drivers, and share various resources in the fashion that the host OS requires. None of that has squat to do with what addressing mode the processor is running in and everything to do with what OS is running, which is why OS'es come with their own drivers. See also: UDDI.

      BY placing these right in the fimware Sun is able to smoke x86 performancewise ALWAYS.
      Bullshit, bullshit, bullshit. The weaknesses of the IA-32 architecture descend mostly from 20 years of backward compatibility for marketing purposes, and the resultant need to handle legacy crap from bit-banging 1980's programs and drivers to 16-bit-addressing DMA controllers to slow ISA peripherals to IDE controllers that you could still run on a PC/XT ferchrissake. More function = more silicon = longer critical path = slower.
      I thin its time to ditch our legacy DOS hardware
      Yes...
      and start getting x86 machines with protected mode BIOS drivers.
      The BIOS is history once any modern OS boots (with the possible exception of power management on laptops). What's in the bootstrap ROMs doesn't fscking matter once the OS is loaded.

      The major problem is the chipsets and the 20-year-old designs they're based around. Drop in full 32-or-more-bit DMA controllers or require all peripherals be bus-master capable, segregate the ISA bus to its own out-of-the-way 16MB window somewhere (see: Apollo DNx000 family), hardwire a handful of interrupts and a hardcoded address range to each slot (see: EISA), drop the legacy keyboard/mouse interface, and redo IDE entirely (see: SCSI). While we're at it, let's scrap BIOS and replace it with OpenBoot. Now there's a machine free of legacy crap that might be worth writing home about.

      -jhp

      • The major problem is the chipsets and the 20-year-old designs they're based around. Drop in full 32-or-more-bit DMA controllers or require all peripherals be bus-master capable, segregate the ISA bus to its own out-of-the-way 16MB window somewhere (see: Apollo DNx000 family), hardwire a handful of interrupts and a hardcoded address range to each slot (see: EISA), drop the legacy keyboard/mouse interface, and redo IDE entirely (see: SCSI). While we're at it, let's scrap BIOS and replace it with OpenBoot. Now there's a machine free of legacy crap that might be worth writing home about.

        Geewiz, that sounds like my Mac (G3).

        But you're right, there is a need for a chipset redesign, not a processor redesign (at least for now). Thankfully, Intel has the Itanium. It's a start, at the least.

        My question is, what do IBM's Power-based systems use to boot?

  • .8 sec... SO? (Score:3, Informative)

    by xanadu-xtroot.com ( 450073 ) <xanaduNO@SPAMinorbit.com> on Monday August 27, 2001 @10:46AM (#2221246) Homepage Journal
    OK, while that's a pretty nice thing, what's the big deal? That .8 sec is only [button push] to the lilo prompt. So? The box STILL has to boot. What if you've got a box that still has to fire up a bunch of daemons before it's even online and usable? What if it was a dirty shutdown (and the silly fool is still running ext2) with a nGig drive(s)? How does this help uptime?

    • Re:.8 sec... SO? (Score:4, Interesting)

      by praedor ( 218403 ) on Monday August 27, 2001 @11:03AM (#2221330) Homepage

      What I'd like to see is an EPROM to contain a kernel. Any kernel. A generic 8 megabyte EPROM that will hold the linux kernel (or, if you are stupid, a doze kernel) and various modules so that you can very quickly bring up your system instead of waiting for this daemon, that daemon, etc.


      Sure, some of this stuff would still have to take place outside the EPROM, delaying powerup-to-input time but it could be minimized by sticking as much as the user wants (and can fit) into the EPROM. It should be generic so that it can hold doze, linux, sunos, freebsd, whatever you want as your primary os.


      My system remains much the same from boot to boot so I wouldn't need to constantly reprogram the EPROM to fit with my latest change. There could be a simple utility like a BIOS upgrader app to handle the EPROM programming. Make it so that it isn't absolutely required so that if something goes wrong with the EPROM you can still boot off you harddrive - which you would need anyway if you use a bootloader and want to bootup another os periodically.


      What is it that prevents this sort of thing? Design mobos with a new chipslot for the kernel EPROM and design the chip to contain enough mem to hold any one of the os kernels that are generally used (or likely to be used). If there is a lot of leftover space, perhaps you could fit another kernel and supporting modules into it until it is full allowing for a very fast dual boot setup.

      • Re:.8 sec... SO? (Score:3, Informative)

        by Telek ( 410366 )
        you think that you can fit everything that you need for a linux or windows bootup in 8MB of flash? You think that you can fit BOTH of them?

        The linux kernel is small, yes, but that's because all of the needed modules and drivers aren't in it! They're loaded on the hard drive.

        Not to mention that flash is very slow... and expensive...

        You'd be better off to store a memory image of a booted kernel at the beginning of your hard drive, along with all necessary information to initialize all of the hardware. Just have a small bootstrap/lilo type of thing that quickly loads up enough to access the hard drive and file system, then load the rest into memory directly, then initialize the hardware.

        But I reboot so infrequently that it doesn't really matter how long it takes. Hell, I have my system set to do a full memory check on bootup. It takes an extra 45 seconds, so what?

        And stop bashing windows... My W2K Server has been up for 145 days now and counting. Check it out along with CodeRedII attack info realtime (yeah, shameless plug [topnotchtech.com]) =>
        • Check it out along with CodeRedII attack info realtime

          Dude, have you looked at your graph recently? You have some negative numbers at the beginning of August. Does your attack counter program subtract from the count when your server tries to attack other servers?

          • funny =)

            Umm, I just ran it and it reported fine, no negative numbers.

            Maybe it can't hold more than one person accessing it at once =). It wasn't exactly written to be robust and hold load. I dunno, I figured that it wouldn't be around for more than a few days so I didn't exactly code perfect...

            • Here, I took a screenshot of it: here [shenknet.com]. I think it might just render different on Mozilla.

              • aah ok, the problem isn't negative numbers, the problem is that you browser doesn't render DIVs correctly... I use a div for the graph with a height setting corrosponding to how high the graph should be (concept! :>) .. I had this problem on mozilla to, it has a minimum height apparently, and if you specify less than that height it displays the box much bigger than necessary. Try to load it with IE or netscape (dunno about the latter, but I know that it works in IE). Thanks for the feedback thou =)
        • You can *easily* fit all drivers to boot almost any given system in 8MB. In fact, you can almost certainly do it in one meg. What you can't do is have all the drivers in existence availabe -- but who needs that?

        • You can definately do it in 16 megs since I've seen a diskless linux box run on just 16 megs of ram. What I'd love to see is a barebones vmware-like OS done in ROM. I'm using windows on vmware on linux now (in raw disk mode) and I forget sometimes that I'm not windows directly, it's that fast (linux on windows sucks however). Of course my stupid BIOS doesn't let me stop the memory check so it takes me god-knows-how-long to check my half gig of memory (vmware loves memory).


          With a vmware-like device you could easily store a memory dump to disk after bootup, and then load that directly into memory every time you restart (unless you need to update drivers).

          • with memory being DIRT FSCKING CHEAP... half gig isn't that out-of-this-world anymore, eh?? =)

            Umm, yes, a totally stripped down and trimmed version of linux could run in 16MB, but a fully fledged and usable version? I doubt if it could fit in 16MB. Do a memory dump sometime to see how much memory your system is using right after bootup, I'd be interested to see actually.

            You can't just do that load-a-memory-image trick because all of the devices in the system need to be in the exact same state that the drivers think that they are in. Thus if you were to just load a memory image, all of the drivers in the system must support hot-reset, including kernel drivers. Windows 2000 finally supports that (hibernate mode), so you could hypothetically boot up, immediately hibernate, and then just always use that hibernate restore. that would speed things up considerably. My system uses about 70MB total on boot (but I'm sure that if they were smart and didn't load stuff that "might be used soon" it could be 40MB. Compressed that's easily 30MB which is just a second or 2 to load off the disk. That's gotta be faster than doing a full boot all the time.

            Anyways, it's not just as easy as it sounds. I don't think linux has it yet, does it? Is it in the works? Do linux users even want it?

            I don't know why they don't implement that as a standard feature, but I'm sure they have their reasons.


            • > with memory being DIRT FSCKING CHEAP... half
              >gig isn't that out-of-this-world anymore, eh??

              NVRam is not "dirt fscking" or any other kind of cheap. Also, RAM for embedded devices is not always cheap like it is for consumer devices.

              Since we're talking about embedded devices, I think it's fair to point this out.

              >Umm, yes, a totally stripped down and trimmed
              >version of linux could run in 16MB, but a fully
              >fledged and usable version?

              It depends on what you mean by "usable"

              I have a notebook I use all the time with only 16MB. It's nothing like "totally" stripped down.
              Trimmed, as you'd do for any notebook install, but not as much as you seem to think. The same notebook runs windows95 just fine too.

              • NVRam is not "dirt fscking" or any other kind of cheap. Also, RAM for embedded devices is not always cheap like it is for consumer devices.

                The comment I was replying to was that the person had a half gig in their home machine, and since 128MB PC133 is $18.95 at the corner store now, fully populating your motherboard isn't expensive AT ALL. I can't believe how fast and quickly memory prices have fallen!! Can anyone else remember when it was like $30/MB back with SIMMs? Then with the DIMM price hike? Damn... So yes, SDRAM is dirt cheap right now =) Kinda pisses me off. About a year ago I paid $400 for 256MB RDRAM off ebay for my P4. Now it's like $81 for the same amount.


                I have a notebook I use all the time with only 16MB. It's nothing like "totally" stripped down.
                Trimmed, as you'd do for any notebook install, but not as much as you seem to think. The same notebook runs windows95 just fine too.


                And what do you run on it? No, seriously. I want to know what you can run on a 16MB laptop, deemed "usable". If you're referring to maybe wordpad or 1 small old application, ok sure. But I remember with 32MB on a laptop trying to run Word with Win95 and it choked bigtime. Took forever to load, was ok to use provided that I didn't try to use any other application at the same time.

                I think the point of this entire thread was that they were talking about doing this to your normal home machine to speed up booting time. I'm just not certain that it wouldn't be a lot easier, and no slower, to just put that block at the beginning of the hard drive and load it from a very simple bios. This way you're unlimited as to what you can do, you don't have to flash to test anything, and since you have to read stuff off disk anyways sooner-or-later during the bootprocess, do it all at once at the beginning and grab your bootstrap/ramimage at the same time.

            • Umm, yes, a totally stripped down and trimmed version of linux could run in 16MB, but a fully fledged and usable version? I doubt if it could fit in 16MB.


              The idea is to put a minimal kernel (no apps) in the 16MB, and then DLKM the rest. Actually, my idea was to put a minimal linux with just enough support to run freemware or some other vmware-like product, directly in the kernel. I have no idea how much space that would take, though. It's basically a microkernel architecture, the meat of the OS (filesystems, networking support, etc) would go on top of it. Besides booting quickly, you'd hardly ever need to reboot in the first place, because the majority of the code will be dynamically loadable.


              You can't just do that load-a-memory-image trick because all of the devices in the system need to be in the exact same state that the drivers think that they are in.


              I did this all the time with vmware. I suspend the linux to disk, reboot windows, then resume. The TCP gets a little messed up, but it's quite simple to just bring the interface down and then up again. Pending disk I/O is presumably flushed before halting the OS execution, I'm not sure exactly how they do it but they do, and I'd imagine most of their work is spent making it compatible with guest operating systems, if you had the actual support of the guest operating system it'd be a lot easier.


              The only potential problem I see for this approach is with gaming. Perhaps it could be worked around with raw I/O access and direct screen writes, or maybe you'd have to modify the intel architecture itself, I'm not sure. But other than gaming, introducing a small amount of latency into system calls is worth it IMHO for the gain in reliability. Again, I'm running windows on vmware on linux and I am noticing zero problems. This on a 500Mhz celeron with half a gig of memory (256 megs dedicated to windows). An earlier article mentioned about how people buy machines which are way too powerful to be used, I think we've reached the point where we can start trading processing speed for features.

        • Desktop operating systems are designed for configurability, not zippy boots for HA. It has reams of code that's only there to make reconfiguration easier. You can pre-set a desktop kernel with its fixed peripheral configurations, but there are embedded OSes designed for that.

          Linux would only be repurposed to do this sort of thing because it's open source, and because hackers understand its operation. That doesn't make it the right tool for the job.

          --Blair
      • Then I suggest you look into this page that is working on a Linux BIOS [lanl.gov].

        Enjoy.
      • What I'd like to see is an EPROM to contain a kernel.
        You mean like LinuxBIOS [linuxbios.org]?

        What is it that prevents this sort of thing?
        EPROM density, tight margins, and low write speed are just three reasons. Sockets, never mind ZIF sockets, are not cheap, and don't even think about SMT sockets. Sure, you can get an 8 megabyte flash EEPROM for about $10 each by the hundred, but you're looking at a good minute or three to burn the chip full. Besides, what happens when your burn fails halfway through?

        I maintain that OS'es should save as much system state across power-downs as they can, along the lines of APM sleep/wake (or better yet using an OS built out of persistent objects that can boot instantly and page in whatever is needed, on demand). Hell, with that no-POSTing BIOS and APM sleep/wake, you can already do a ten-second power-on without harming any non-volatile memory devices whatsoever. THIS IS NOT ROCKET SURGERY, FFOLKES.

        -jhp

    • This BOIS is a building block to be used in a system that needs to power-up quickly. An example of a place it might be used is a set-top box. People don't want to wait 20 seconds for their TV to come on, and people have also become a lot more aware of appliances that don't really shut down when you turn them off. I can see a market for this BIOS, but I don't really see it in the high availability market.

      In my limited experience with a telecom product that needed 5 9s uptime, everything had a level of redundancy, because you had to assume some hardware was going to fail. That means that you are possibly running at reduced performance while the system is comming back online, but the system doesn't go down just because part of it was rebooted. The 79s thing sounds like something someone in marketing though sounded good, even if it's not that applicable. It has that cool buzzword, marketing feel to it.
    • My VIC-20 will also boot up in .8 seconds, and it only has a 1-MHz processor, and it'll go all the way up into the command-input mode!

      READY.

  • Geek (Score:5, Funny)

    by TheLoneCabbage ( 323135 ) on Monday August 27, 2001 @10:46AM (#2221248) Homepage
    Wow! Geek perfection! Cold to LILO in 0.8 seconds. Women will flock to me!

    Now if I can just get LILO working again...

  • Okay, for everyone alternatively complaining that this is overkill on the desktop, or that they would prefer all the checks, etc. in place... this is NOT built for desktop systems.

    Read the post; this is for an embedded system requiring seven nines. Though it can (and most likely will) be adapted for desktops, any desktop running this will be a high-reliability server, with all the checks (except memory, which this chip does after a fashion) built into the hardware...

  • slashdot (Score:5, Funny)

    by Anonymous Coward on Monday August 27, 2001 @10:53AM (#2221286)
    Slashdot also has seven-nine uptime. Except it's not 99.99999%, it's 9.999999%.
  • My ][e could boot to a command prompt in less then 1 second. A fast (by historical standards) HD meant a boot to a DOS was easily only a couple of seconds.


    (This is probably going to be flagged as a troll or flamebait, but think about it. We have put up with crap for so long, that when we finally get sub-second boot times back it's a big deal. It's like hiding toys from your kids for 6 months and then bringing them out as winter sets in - they get all excited about stuff they used to have.)


    I'll admit ignorance as to all the required checks, double checks and initialization that must go on to get a decent OS up and running, but I still can't help but think that inefficiently designed / written bloat-ware could be done much better to improve the boot times of modern machines. Why not lazy load the drivers, etc as required?

  • soyo and 7 nines (Score:2, Interesting)

    by bziman ( 223162 )
    The embedded system was clocked at 0.8 seconds from system power-on to transfer of control to LILO. This was on an Intel SOYO motherboard (440BX chipset) running a PIII 400

    Two comments:

    Doesn't Soyo mean "gentle" in Japanese?

    And, if you really need "7 nines" uptime, you shouldn't be relying on a single processor -- you should be relying on a processor farm that supports hot-swappable processors, so you can lose one or two or fifty and only lose a fraction of performance for as long as it takes to replace those processors.

    On a high availability machine, there should never be any reason to reboot until you must upgrade the kernel, and I'm sure there are ways to do that without requiring a hard reboot. IBM has had farms like this for years.

    --brian

  • Rather, I think the issue is minimizing the unexpected downtime that occurs at a critical moment. Lets say you are using a computer in surgical equipment. Let also say that, heaven forbid, there is a bug in the software code. While the surgeon is busy fiddling around inside the patients head, the equipment freezes up. Every second that it takes to restart the equipment, there is the possibility of harming the patient.

    Obviously, equipment this critical should never ever crash. It's nice to know, though, that should something happen, the equipment will restart quickly.

  • 99.99999% uptime per year?

    3.15s/year downtime.

    This is possible with a reboot? of any machine? Even if the post takes 0.8 seconds?

    I think the only way to have that type of uptime is to not go down at all.

    Or of course, you could say that you have a 99.99999% uptime (average, over 1000 years) ;)
  • Unfortunately lilo is set to prompt with no timeout, it sure gets there fast though.

  • stinking devices (Score:5, Insightful)

    by lildogie ( 54998 ) on Monday August 27, 2001 @11:37AM (#2221474)

    for a device that must support "seven nines"

    (my emphasis)


    A pet peeve of mine is that PHB's think that "device" uptime is the same as "system" uptime.


    Decades ago, we had fault tolerant systems that had large-chunk redundancy. An entire mainframe could fail and the system kept serving.


    OTOH, haven't you ever had a failing app take down your system, while running on perfectly healthy hardware?


    The reason this misconception, that perfect-hardware==perfect-uptime, frustrates me, is that the PHB's get sold this bill of goods by hardware salespeople. Then they don't even allow for downtime to upgrade the effing OS every two years. Nor do they allow for a second system to either (a) take the load during an upgrade, or (b) test updates to the application.


    For this silly reason, giant, fault-tolerant boxes are hurting, rather than helping, high-availability computing. Bosses would rather spend money on sexy hardware that won't solve the problem, instead of paying smart people who can design-in the uptime with combos of hardware, software, and procedures.

    Quench-rant (for now).

  • ....if only I could get my X-windows profile to load in .8 seconds. Ahhh...

  • Fast Boot is also a User Interface issue (Score:3, Informative)

    by drivers ( 45076 ) on Monday August 27, 2001 @11:46AM (#2221502)
    Even though this BIOS was intended for embedded machines, fast boot is also important for desktop PCs. Consider the Canon Cat designed by Jef Raskin (see "The Humane Interface" by Raskin). It takes a very short amount of time to boot, all you have to do is start typing and the computer powers on and loads the operating system, putting the cursor in the document exactly where you left it off. Not only that, but there is a hardware buffer for the keyboard so that it doesn't even lose the keys you typed while it was booting up. Now that is a computer designed with the user in mind. I'd like to make a PC operating environment and the first thing I'd do is make sure it boots fast. I was thinking the BIOS would be the slow part but if it's possible to speed that up, then that is all the better.

  • On the BIOS topic, do you know where I can find BIOS that talks via ttyS0 instead of the video card?

    To me, this is a requirement for servers. It means I can completely administer it remotely via a cheap terminal server. It also means I can dump the video card in my servers. Sure, Linux can use the serial port for its console, but that doesn't help me when Linux isn't booting. I know there are remote KVMs, but they aren't the cheapest thing in the world.

  • Got Math? (Score:2, Insightful)

    by Kasreyn ( 233624 )
    Let's get out our calculators, class...

    365.24 days per year (from Space.com. I don't know of any more accurate (more decimal places) numbers than this. Even if you were to add 5 whole days to the year though, it won't even add one one-hundredth of a second to the final result, so I think we can go with this).

    99.9999999% of 365.24 = 365.23999963476

    365.24 - 365.23999963476 = 0.00000036524 days

    This is the maximum allowed downtime.

    Assuming a day is exactly 24 hours long (I'm fairly sure it is),

    0.00000036524 days = 0.00000876576 hours

    0.00000876576 hours = 0.0005259456 minutes

    0.0005259456 minutes = 0.031556736 seconds.

    Thus, 99.9999999% percent uptime requires NO MORE than ~0.0315, that's three hundredTHs of one second, downtime, per year.

    Nope, don't think we're there yet, but you keep pushing that 99.9999999 number if it makes you look good. After all, the general public can't do math either... =)

    -Kasreyn
    • Your close.

      Your calculating for 9 9's. They count the two before the decimal place too.

      If you allow for 100x as much downtime, you;d get 3.15 seconds, for 7 9's. Which is what they quote.
    • That's nine nines (99.9999999%)

      seven nines is (99.99999) and that makes your calculations 1/100th of what they should be. The final answer should be about 3 seconds/year in uptime.

      Uptime of the computer, I suppose, is what this handles, although I don't believe the OS boots in .8 seconds, just the bios. And the server you may want to keep up might not boot in the .8 seconds either.

      Plus this doesn't deal with other problems such as why the computer went down in the first place.

      -Ben
    • I thought they meant 7 nines after the decimal place. =P

      Hehe.

      -Kasreyn
  • That means, if you add the 75 seconds for windows to boot, you get... oh. about same as it was.

  • MRBIOS (Score:2, Informative)

    by bored ( 40072 )

    News, hmmp, check out MRBIOS [mrbios.com]. I first discovered them back in 92/93. Back then they had auto IDE detection, support for big IDE drives, and of course a FAST boot option. A year or so after that they had (software like the promise) IDE RAID support in the BIOS. Today I still have a VLB 486 machine (my firewall/webserver) with MRBIOS. It has a 60 Gig harddrive and a 16.7 Gig harddrive plugged into it with a massive uptime ratio (greater than a year and a half at up at one point). The machine is sub .8 second warm reset times. Its basically instant. The screen clears and lilo starts booting linux (I have lilo configured not to stop unless the shift key is held down) if I press the reset button. If the machine is comming up from a cold start the bios flashes post for something less than a second and then displays a flashing "Waiting for Harddrive to spin up" while the harddrives are going Whhhhhhhhmmmmmmm... As soon as they sound spun up the machine starts booting. I have machines that are 3 years old that don't support 16 gig drives and this little box is getting on towards 10 years old and it has a 60 gig HD plugged into it. I put a dx4-100 overdrive in it a few months back and the board which was bought right when the Dx2-50's first appeared. Poped up and said,"Newer than Dx2 486 at 99mhz" ,or something like that.



    Its really sad though that these guys never caught on. Most of the 'cool' bios features that have appeared in the last few years in award/AMI were in MRBIOS in the early 90's. Now they are just a shell of a compay and they don't have BIOS's for machines newer than a few years old. Some people are just ahead of their time, Well I guess i'm going to go home and reboot my machine from the third harddrive now... lol..

  • I used to use General Software Embedded BIOS. It was truly awful. It came with source code (note it's NOT open source), and there were nasty bugs in the code, in files that hadn't been touched in years. The performance was awful, the development kit was clunky, the documentation was poor, and the code was crap. My impression was that of a company that spent very little time developing software, and were mostly interested in squeezing the last few dollars out of an old, mostly unmaintained lump of code that had very little value left in it.

    The idea that someone today would actually _want_ a 16-bit legacy BIOS in a newly designed embedded device is laughable. The only reason to do it is if you want to run embedded DOS (gag!) or Windows, which ain't likely if you're shooting for 99.99999 percent uptime.

    Now I use a variation of Linuxbios. It works great, it's free, and I'm free from debugging somebody else's crappy assembler.

  • LinuxBIOS [linuxlios.org] is at least that fast and is GPL. It's also been around for at least a year now.


  • Tandy 1000HX (Score:3, Informative)

    by fishbowl ( 7759 ) on Monday August 27, 2001 @02:20PM (#2222219)
    Am I the only one here who remembers DOS3.3 machines that had DOS in ROM? By the time you took your finger off the power button, you were at the prompt, or your autoexec had run.

    • I was reminded of the old PCs just last night, when trying to configure LILO on a new PII-based Linux box.

      On the first reboot, it came up, POSTed, and acted normal. Instead of LILO, what instantaneously appeared on the CRT was a message saying "CANNOT FIND ROM BASIC - SYSTEM HALTED".

      It was beautiful, in a 40-column white-on-black font that I hadn't seen used in years.

      I stared at it in awe for several minutes before rebooting to see it again. =)

  • 2.2 Seconds (Score:3, Informative)

    by B.D.Mills ( 18626 ) on Monday August 27, 2001 @07:54PM (#2223486)

    Now that we've got a PIII booting in 0.8 seconds, to achieve "seven nines", we have 2.2 seconds spare. What can we do with this time? I'm sure we can do a lot of valuable system maintenanace in this time that we would not have otherwise been able to do.

    We could:

    • Swap out a dead power supply.
    • Replace a faulty memory module.
    • Swap the UPS for one that has its own in-built generator.
    • Put fluffy dice over the console.
    • Change the grey cables for ones in designer colours.
    • Wave a dead chicken over the console.
    • Upgrade the mainboard.
    • Look busy so marketing can't have the latest item in their wish list installed.
    • Remove the thing that marketing wanted installed because it's making the system unstable. If it's not unstable, you would not be rebooting, would you?

    Of course, you might have to work fast....

Slashdot Top Deals

HELP!!!! I'm being held prisoner in /usr/games/lib!

Close