Slashdot Mirror
Ask Slashdot: Faster Reboots?
RobertPearse
submits this question: Here's an article about
ILM engineers using a small
Linux box to reboot systems quickly. They mention a "TTL
data-acquisition card". Housed in a linux box, it allows
them to reboot a system very quickly. Anybody know
anything about this? My company is a Microsoft shop -- and
given the fragility of NT, this sounds like a great idea.
(God forbid we need to reboot an NT box ;-)"
That sounds nice, but there is a big problem with that. Assume you save the state of the machine (say at time point x) and a few seconds later (time point y) the machine BSODs for some software reason (say NT is flaky). Now you reboot the machine and load it back to state x, what is going to keep it from crashing at state y all over again?
These sort of protection schemes are really only good at protecting you from hardware failures, which is not what you are looking for. Also, if your system has a lot of memory it can take quite a while to dump the memory to disk and read it off again on boot. I work on machines that routinely have 4GB of memory, and when they crash (and core dump) it can easily take 15-30 minutes to finish dumping the core. These machines can boot regularly in less than 10 minutes (easily). Of course with the checkpointing scheme you don't lose as much work, which is a big thing when you are using the machine to do an extremely computationally intensive task or have a huge database in memory.
I read the internet for the articles.
The only thing I have done to speed up my Linux box boots is probably the worst thing you could do. And so it's not something I am recommending at all.
Given that the standard ext2 filesystem forces an fsck every 16 mounts, I was having to sit through long, slow, irritating fscks about once every week or two. So I used ext2ed to change the forced fsck to every 64 mounts instead.
This is not recommended because you have a greater chance of losing data. But, it makes those fscks happen alot less frequently!
Many laptops save the entire state of the system when you put them in 'sleep' mode. The contents of RAM, register values, program counter location, etc., are saved to disk. When you power up the machine again, everything's quickly reloaded and continues where you left off.
For faster reboots, all you have to do is reboot, let the system come up, and then save the state of the system at this point. Later when NT goes BSOD, you just reload your freshly rebooted image which is much faster than a true reboot, since the time it takes to restore a system state is essentially the time it takes to reload RAM (128MB tops) plus state info (insignificantly sized chunk of data).
Most importantly, the runlevel stuff (SysV initialization) is just abysmally slow. If you want fast reboots, put just what you need into /etc/rc and get rid of all the other stuff.
It also helps to make a custom kernel that includes only the modules and drivers you need.
If you have certain kinds of hardware or controllers in your system (Adaptec comes to mind), trying to achieve fast reboots is hopeless because they need lengthy initialization routines and microcote downloads.
This kind of setup isn't good for many day-to-day uses, and it will probably cause problems with distributions like RedHat or Caldera. But if you want fast reboots, you can get them. Last I did this was on an older distribution of Slackware.
Welp, I openly admit the following is theoretical.
The key to fast reboots is to do the "Rapid Resume" type of stuff that IBM PCs used to loadly boast as a feature several years ago. Basicly, on demand, it would write the contents of memeory to a special place on the Hard Drive. Whenever it boots up and goes through POST, it looks to that area, reads in the data to memory, and resumes at the exact spot it was before shutdown, almost instantly.
There's no reason this type of technology couldn't be used in other other way. I would guess that in this case it uses of a card with flashable memory, and saving state where it is right after a boot or right before doing a process that could crash a system...
We'd use a run of the mill data acquisition card (MEI, Axiom, choose you're evil). These cards use basic TTL I/O, so we'd hook it up to an opt-relay, and could switch on/off computers, servos, and PLC's... The axiom and MEI had nice C libraries... The only problem is I think the smallest I/O batch they came in was 25 per card. But the cards weren't that expensive at the time....
Jeremy
"Opinions are like assholes; everyone's got one..."
Yeah, it sounds like a standard digital I/O card was connected up basically to emulate pushing the reset button on the front panel. Omega Engineering makes a lot of varieties of these things, and will send you scads of literature and stacks of Dilbert comics too. See Omega Engineering TTL I/O cards for some of the available ones. Nothing too exciting, just a very practical use.
Enjoy your job, make lots of money, work within the law. Choose any two.
If slashdot is not responding, go to http://reboot.slashdot.org, and press the big red button on the page. This triggers a perl script which drops a TTL line low, which triggers a relay connected to the reset button on the slashdot server.
:-)
Use with care
I love it!
the AntiCypher
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on