Reducing OS Boot Times for In-Car Computer Applications, Part II
In our last article, we discussed the motivation for wanting boot time reduction. As discussed, we are trying to create as "instantly on" an experience as we can for in-car computers. We're taking a holistic approach to the problem by looking at every place that the system delays during bootup and trying to list all our options for reducing the times in that area.
You may have noticed over the last several years that the delay has increased between when you start a car and when you hear the radio. When head units were simply analog FM and cassette adapters, music would start blaring out, at the current volume, the instant the car was started. These old stereo units had analog potentiometers for the volume control, analog tuners to get the FM signal and analog tapes that instantly started producing sound. Nowadays, a CD player/FM tuner is a mini-computer. The volume can be set to a non-blaring volume automatically between startups. The buttons and knobs now used rarely are potentiometers; they merely send plus/minus information to the tuner controls. To play a CD now requires spinning up the CD, and the firmware on these devices has to boot up, going through some sort of POST (power-on self-test). Sometimes the newest devices actually have to talk to the car's computer, adding additional delay.
There are other reasons for the increasing delay. When aftermarket amplifiers are installed in a car, you often have a staged system where the head unit turns on and sends 12 volts back to an amplifier, which then turns on, at which point you get sound. The amplifier has to charge up its capacitors and level out its power in order to produce high volume. Thus, you now have a cascading delay effect where the car turns on, then the head unit (radio) boots up, then it tells the amp to power on and then the amp boots up--thus, it takes several seconds before you hear anything. If the amp is wired to start up at the same time as the head unit, you may experience a loud pop as the amplifier pumps out transient voltages from the not-yet-powered head unit. They even sell devices that add several seconds of delay to a 12-volt line to solve these popping problems.
So while the BMW 7-series navigation unit is engineered to show a video splash within milliseconds, the norm for audio devices is to produce output after several seconds. Thus, it is reasonable to give this same leeway to an aftermarket in-car computer. However, fully booting an in-car PC can take almost a minute. The question is, how does one reduce that time?
Booting many homebrew in-car PCs can take, literally, a minute. A lot of the delay results from the operating system booting or waking up from hibernation, but it's worth looking at the entire sequence to establish a baseline for the hardware we're using. For the purposes of our analysis, booting up a computer in a car consists of the following steps:
Car power stabilization: The 13.8V power line, which dips down to as low as 6V or gets cut off during engine cranking, must stabilize over 12V. This takes fractions of a second but it does take time. (Cost: ~ tens of milliseconds)
Power supply/regulator stabilization: The circuitry that powers the engine, be it a 120V inverter or a DC-DC power supply, and the associated power regulation circuitry that delivers clean 12V/5V to the computer must stabilize. Inverters can take several seconds to deliver 120V, while DC-DC boards are pretty quick. (Cost: ~ hundreds of milliseconds to seconds)
Power sequencer hits ATX-on button: This step can add time. Many motherboards now have a wake on power loss feature (technically a wake after power loss) that makes them instantly start up when power becomes available. However, many power sequencer/shutdown controllers, which make sure computers turn on and off with the car, tend to add delays to start-up. They usually give the power supply 2-3 seconds to fully stabilize its voltage at 12V; if this doesn't occur, the motherboard can hang on boot. (Cost: up to 3 seconds)
POST: The power-on self-test is the first part of the bios code. This can be reduced greatly but not eliminated by disabling memory checks, startup flash screens, floppy seeks and the like. Without getting a custom BIOS, however, this still takes time. In practice, it can be reduced on some motherboards to less than a second. (Cost: ~ 1 second)
BIOS: These are the rest of the BIOS functions that occur after the possibly necessary self-test. They include a variety of auto-configuration of plug-and-play settings, auto-detection of hard drives, power management and the dreaded DMI pool message that lingers on the screen for many seconds. This is the bulk of the pre-OS boot time. (Cost: ~ 1-10 seconds)
Bootstrap: This doesn't take long at all, but this step can vary based on the boot device. Because it could be hard drive or Flash, at the minimum you have the access time and transfer speed of the device, so it can take several tens to hundreds of milliseconds. If this is a two-staged process, as can be the case with boot loaders (that redirect from the beginning of the disk to some offset on the disk, if I understand correctly) that can add a bit more time. Although the latency of the disk or solid-state memory can change this bootstrap timing, the more important impact of changing the disk is in the boot times discussed below. (Cost: ~hundreds of milliseconds for bootstrap; tens of seconds to minutes for actual OS load)
Run boot loader: This step of the process is the first time we get to run code we may have written. In the Linux case, this would be GRUB or LILO. (Cost: less than a second)
Operating System and Drivers: This step is the long (potentially upwards of a minute) leg of our journey to a user prompt. The baseline we used when benchmarking this particular step is the venerable DOS, which boots in about the same time as the Linux boot loader. The worst case would be a full install of some operating system, un-tuned, with tons of unnecessary drivers, which could take another minute to boot. (Cost: Un-optimized, over 60 seconds. Somewhat optimized, as low as 15 seconds. Goal, less than five seconds).
Show user prompt: The OS eventually must finish booting and show the prompt, whether that is a GUI screen, a text prompt or a voice prompt for audio commands. At this point the system must be fully functional and able to accept any commands.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Why Python?
- Tech Tip: Really Simple HTTP Server with Python
- A Topic for Discussion - Open Source Feature-Richness?
- Not free anymore
51 min 41 sec ago
4 hours 38 min ago
- Reply to comment | Linux Journal
4 hours 46 min ago
- Understanding the Linux Kernel
7 hours 1 min ago
9 hours 31 min ago
- Kernel Problem
19 hours 34 min ago
- BASH script to log IPs on public web server
1 day 1 min ago
1 day 3 hours ago
- Reply to comment | Linux Journal
1 day 4 hours ago
- All the articles you talked
1 day 6 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?