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