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.'"
sometimes i would like to have a sec more to press the delete button to get into the bios and change a few settings.
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.
I am disrespectful to dirt! Can you see that I am serious?!
It's taken 20 years, but they finally got a system
that can boot faster than a TRS-80.
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?
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
Wow! Geek perfection! Cold to LILO in 0.8 seconds. Women will flock to me!
Now if I can just get LILO working again...
I would rather be ashes than dust!
Slashdot also has seven-nine uptime. Except it's not 99.99999%, it's 9.999999%.
>I mean, seriously, what's the big deal if it's >0.8 seconds from power to LILO? I, personally, >would rather have a BIOS that takes a few >seconds to check the RAM, auto-detect devices, >and check SCSI drives before it tries to boot >the system.
It says "embedded system". If you put a cpu in as a brake or steering controller into something that moves at any reasonable speed, you would like it to return service as soon as possible after a power glitch.
No, this does not mean that they make embedded controllers with crashes as a design goal. It means they want to make something that is as error-resistant as possible. Not for your desktop box, in other words.
Obtw: very few of those systems have anything like Linux or Windows on them, even though some people would like to tell you otherwise.
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.
http://developer.intel.com/design/intarch/pentiumi ii/pentiumiii.htm
It shows a low power pentium III at 400 MHz.
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) =>
If God gave us curiosity
(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).
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.
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.
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.
-fb Everything not expressly forbidden is now mandatory.
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:
Of course, you might have to work fast....
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke