Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Linux Software

Ask Slashdot: Faster Reboots? 28

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 ;-)"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Faster Reboots?

Comments Filter:
  • 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.
  • by jandrese ( 485 ) <> on Monday May 24, 1999 @11:05AM (#1881187) Homepage Journal
    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.
  • 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!
  • by root ( 1428 ) on Monday May 24, 1999 @09:25AM (#1881190) Homepage
    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).
  • My Hyperdata P2-300 64MB RAM takes a whole 15 seconds tops to reboot. Not even Linux can boot up that fast if you have to do an fsck.
  • 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.

  • 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 Micro-Research BIOS ( reboots in probably 1/10 the time of any other.
  • It was a joke!

  • On every laptop I've ever had, once you have 64-128MB of memory, the RAM reload process is much slower than an actual boot.

    On big x86 servers (especially EISA machines like Compaqs), the BIOS POST time is almost as long or longer than the actual operating system boot.
  • by jetson123 ( 13128 ) on Monday May 24, 1999 @01:26PM (#1881197)
    I have set up Linux machines to reboot in under ten seconds from past the BIOS check to login prompt.

    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.
  • 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....
  • 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? :)


  • Aww, but Uncle Owen, I wanted more than 12 outputs! I've got a traffic light and a toaster I want to connect to the Internet for novelty's sake.

  • I think the catch is that your hardware and device drivers have to be designed to support a restart. That means the driver must be able to reset the hardware to a known state and reload a checkpointed configuration. I've heard that this is difficult with some video cards. There is a lot of on-board state that isn't saved anywhere.
  • I believe the Linux box was used to reboot wedged SGI [] - Challenge XL []render servers, which have special system controller ports.
  • Use the printer port. You have 8 outputs (bidirectional if you're lucky), 5 inputs and 4 open collector pseudo-bidirectional signals. Great fun, and basically no cost. If you have a highly valued motherboard, invest in a spare parallel port ISA card for about $15 bucks...
  • 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.

  • 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.
  • You can change /etc/fstab to mount /usr
    read-only by default, then manually remount
    it read/write when you need to install or
    upgrade stuff. AFAIK read-only mounts don't
    count toward the maximal mount count for fsck.
  • If slashdot is not responding, go to, 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

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"