by Eric Secrist, Taos Unix Technical Consultant
Why doesn’t my server boot as fast as my iPad? I like my iPad-mini not just because I can take it anywhere, but because I don’t have to wait very long for it to boot. A simple test revealed that my iPad-mini boots in about 30 seconds. If the iPad is in a sleep state, which is essentially a power-save mode, then in one press of the button it’s awake and ready for use. Most servers also have a sleep mode, aka power save mode, but it’s usually disabled, as it’s been known to cause problems in production environments. In general, a server needs to be readily available 100% of the time.
The majority of servers running on physical hardware require a relatively lengthy boot process. The elapsed time between a power button push and login prompt varies of course. Older IBM pSeries hardware running AIX can take over 20 minutes to display a console login prompt. Modern Oracle SPARC servers running Solaris can test your patience as well. Physical Linux servers on x86 hardware can also take several minutes to boot. In a business environment, speeding up the boot process or completely eliminating it would improve availability.
In order to improve the speed of a server’s boot time, it helps to understand the typical boot process for a Linux server running on x86 hardware. The control of the boot process is shared by multiple phases. First, the BIOS is executed, then the boot loader, and then finally the kernel and init phases. Further details about each phase are listed below:
1. BIOS – initializes the hardware, including the CPUs, memory, buses, etc., loads the boot loader and executes it
2. boot loader – provides boot options, loads the OS, and starts the kernel.
3. kernel – sets up scheduling, and starts the init process.
4. init – executes scripts and ultimately presents the user with a login screen.
(“Linux startup process”, 2014)
Let’s focus on the initial part of the BIOS process. The Basic Input/Output System, or BIOS, is the first software that is executed when a server is powered on. The BIOS is stored on an NVRAM chip on the motherboard, which is specific to the hardware model. Unlike RAM, which cannot store data without power, NVRAM is power independent. For example, the /tmp filesystem on a Solaris server resides in RAM. When the server is power-cycled, the /tmp file system is destroyed, and then re-created after power is restored. All data stored in the /tmp file system is lost when the system loses power.
The BIOS is also referred to as firmware, but not all firmware is part of the BIOS. Firmware is necessary for nearly every computer. The firmware tells the hardware in the computer how to initialize itself, so that the hardware can communicate with other pieces of hardware. For example, a CPU must know how to start itself with the proper memory registers, so that the CPU can interact with the memory and other hardware components in the computer. Naturally, the time it takes for the firmware to complete is a function of how many hardware components a computer has. Most servers today are multiple CPU systems.
One of the primary reasons for a relatively slow boot process for multiple CPU systems is the lack of parallelism during the firmware initialization right after power on. Hardware resources that a server normally uses for parallel processing, such as memory and buses, are simply not available immediately after a power on. The result is a relatively slow, serialized boot process. (Amman, 2013, p. 1)
In an attempt to “parallelize” the boot process, a few different approaches exist. One of the most prevalent approaches for servers is the use an external piece of hardware called a service processor, or SP. The SP handles the memory addressing and configuration of the CPU chip-components in parallel, but the speed of the processing is limited by the resources of the SP itself. Some examples of server hardware that use an SP include Oracle X86 servers, IBM Power Servers, and Oracle T-Series hardware.
Other approaches to speeding up hardware initialization include “tricking” the CPUs in a multiple-CPU chip system into thinking that they are the only CPU in the server. Each CPU starts in parallel, not realizing that there are other CPUs in the system. Later in the hardware initialization process, a master CPU and slave CPUs are configured and the address space for each CPU is unified. (It’s much more complicated than this – see Amman, 2013, p.1)
The growing trend towards virtualized servers is also helping speed up the hardware initialization phase of the boot process, and depending on the type of virtualization, the kernel phase as well. In general, virtualized systems that use an already initialized kernel boot more quickly than a server that is fully virtualized. Examples of fully virtualized systems include VMware guests and Solaris LDOMs. An example of a virtual system that shares a kernel is a Solaris zone. A Solaris zone can essentially skip the hardware and kernel initialization part of the boot process, which speeds up the total boot time significantly. Depending on startup scripts, some Solaris zones can boot in less than 10 seconds.
All virtual servers are not subject to the serial hardware initialization constraint that a physical system is dependent on. A virtualized server is hosted on physical hardware that already has all hardware resources initialized and available for use. The hardware initialization can be completed in a parallel fashion.
The Apple iPad simply has less hardware to initialize, which makes the boot process much faster. Incidentally, an apple iPad stores all of its data in flash memory, which is essentially NVRAM. Comparing an iPad to a server is simple not an “apples-to-apples” (tic) comparison.
Linux Startup Process. (n.d.). In Wikipedia. Retrieved February 15, 2014, from http://en.wikipedia.org/wiki/Linux_startup_process
Amann, E., Haverkamp, F., Huth, T., Kunigk, J. (2013). US Patent No. 0151829AI. Washington, DC: U.S. Patent and Trademark Office.