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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide