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