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 ;-)"
I doubt that this will work. Indeed, while
working on the computer, the contents of the
disk (filesystem) changes, and that content would
be no longer consistent with the memory image
which was taken just after the reboot.
reboot.slashdot.org doesn't resolve to anything.
I haven't tried this but ... As long as you want output only, with some extra TTL circuitry you could have a maximum of 128 outputs from that one printer port. Connect the 4 bi-directional lines to a demux chip. Each output of the demux can enable one 8-bit latch. Use an array of 16 8-bit latches for your outputs.
What it sounds like they are doing is that they hooked up the TTL output to the reset lines on the keyboard controllers of the other computers. Basically the same thing as pushing the reset button on the front of the case, but can be done by software control remotely with heartbeat monitoring. One could probably even make a cheap rig to do this using the parallel port and some opto-isolators.
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.
Nothing. But the second boot won't load the RAM image off the disk. Each RAM image only loads once (at least on my laptop). If you were to load a RAM image off disk, and then you immediately crashed, your next reboot would not load the RAM image off disk. The only time a RAM image will be loaded and run is if saving an image to disk was the mechnism you used to shut down last.
In other words, it's not a problem.
My laptop is faster at loading the 64M (+ 4M video RAM) image off disk than it is at booting up to Linux + X. Add in the extra time it takes me to start the applications and a regular boot becomes even slower. Which is why I always use the suspend-to-disk option of my laptop.
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).
This sounds like some of the products that I cam across in the back of some IT/Network magazine the other day. In about 10 pages of ads, there were at least four 1/4 page ads for products that would let an admin remotely reboot machines. I guess with the spread of NT into corporations, I guess devices like this are becoming a necessity. Although, from Rob's post today, it sounds like until he gets the hardware drivers ironed out, Slashdot might need one.
the good ground has been paved over by suicidal maniacs
I remember reading about that feature of win98 in some PC magazine. When the authors of the article tried it out, it saved something like 2 seconds off the 10 second load time for Word, but to do so it took about 2-3 hours for the optimizer to reorder the hard drive.
the good ground has been paved over by suicidal maniacs
The Micro-Research BIOS (www.mrbios.com) reboots in probably 1/10 the time of any other.
It was a joke!
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...
Its been done on windows to reduce loadtimes of applications. I think the first one was called windrenalin but now its part of w98.
I believe I read the article last week, and it sounded like they were saying that they were using linux to hardware reset the card (since they had complete control of the OS) by bringing the voltage supplied to the card way down (simulated reboot). I haven't time to re-read it since I'm pretty busy right now, but that what they were saying AFAIK.
-earl
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..."
Anyone know of a cheap supplier where a poor, experimenting college kid could get one of these? Or, maybe you have an old one sitting around you wouldn't mind selling/giving away? :)
-Chris
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.
Perhaps it saves reboot time because it's on a more stable box? I assume the hardware and drivers do not need much rebooting, but rather the applications that cause problems. If you have very thin application boxes (RAM, disk, Windows NT), they would reboot faster than if they were loaded up with lots of drivers that would need initialisation.
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