Slashdot Mirror


Booting A PIII System In .8 Seconds

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

5 of 353 comments (clear)

  1. About time - was able to do this _years_ ago by ehud42 · · Score: 2, Interesting
    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?

    --
    I'm in my right mind and I have the answer to everything!
  2. Re:.8 sec... SO? by praedor · · Score: 4, Interesting

    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.

    --
    In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
  3. soyo and 7 nines by bziman · · Score: 2, Interesting
    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

  4. Re:Get a "REAL" Computer by marxmarv · · Score: 4, Interesting
    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 Free Republic of technology.
  5. 99.99999 is five 9's, not seven by Anonymous Coward · · Score: 1, Interesting

    Seven 9's would be 99.9999999

    you don't count the first two. M$ lies. They call 99.999 five 9's, that is not true and I doubt they can ever get that on an actice system