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.'"
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.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
-zr
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.
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...
I am disrespectful to dirt! Can you see that I am serious?!
>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.
99.99999% uptime = 3 seconds downtime per year
99.9999% uptime = 31 seconds downtime per year
99.999% uptime = 5 minutes downtime per year
99.99% uptime = 52 minutes downtime per year
99.9% uptime = 8 hours downtime per year
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...
I am disrespectful to dirt! Can you see that I am serious?!
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
Then I suggest you look into this page that is working on a Linux BIOS.
Enjoy.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
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.
News, hmmp, check out MRBIOS. 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..
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