10

EFI can be faster, but that's not certain. The biggest speed difference is in hardware initialization early in the process. On my systems, this is a fraction of the total boot time, so a reduction in the hardware initialization time, while good, doesn't make all that much difference. — What is the difference in “Boot with BIOS” and “Boot with UEFI”

After reading this, I am wondering how much will the difference be. While watching a movie for a Gigabyte mainboard where the UEFI versus classic BIOS boot time is at 11 versus 19 seconds, I see loads of hardware enumeration and display during BIOS boot and that it boots into some kind of Windows menu. My BIOS boot doesn't do that, so I need to extend my question.

For firmware with already tweaked BIOS settings, that boots into a single OS (Linux text console operating system). No dual-boot OS here. BIOS boot in this case is a boot with UEFI having Compatibility Support Module (CSM) enabled. A tweaked legacy BIOS is one where optimizations are made to already reduce boot time (speed up the boot process).

How many seconds faster will an EFI boot be over a tweaked legacy BIOS boot (UEFI+CSM)?

Community
  • 1
Pro Backup
  • 4,924

1 Answers1

10

Measured results:

BIOS - fast boot = 14.15 seconds
BIOS + fast boot0 = 13.08 seconds
UEFI - fast boot = 13.01 seconds [1.14 seconds faster]
UEFI + fast boot0 = 11.30 seconds [1.78 seconds faster]
UEFI + ultra fast1 = 10.87 seconds

Even more optimizations by removing GRUB boot loader:

UEFI stub + fast boot0 = 9.84 seconds
UEFI stub + ultra fast1 = 8.20 seconds
UEFI stub + ultra fast1 + static IP2 = 6.38 seconds3

0. In "fast boot" mode the computer may not boot from an USB storage device.
1. In "ultra fast" mode the video BIOS must support UEFI GOP if you are using an external graphics card. Please notice that Ultra Fast mode will boot so fast that the only way to enter this UEFI Setup Utility is to detach all boot devices.
2. No DHCP client active.
3. ASRock's claimed 1.5 seconds to logon to Windows 8 from a cold boot is actually 9.85 to 9.88 seconds on this system.

Environment

For this test an Asrock H81 Pro BTC P1.50 mainboard is used, connected to it are:

  • 2.7Ghz Intel Celeron G1820 CPU
  • 8GB RAM
  • OCZ Vertex SSD (ahci, agressive power management enabled)
  • LAN (100 mbps)
  • PS/2 mouse & keyboard
  • USB keyboard
  • VGA
  • Supermicro PCIe HBA (Marvell chip based, no drives attached)

The motherboard firmware is set to:

  • Full Screen Logo = disabled
  • Boot Prompt Timeout = 1 second
  • Boot From Onboard LAN = disabled
  • Boot Failure Guard = disabled
  • Secure boot = disabled
  • Intel Smart Connect Technology = disabled
  • Unused hardware = disabled (HD audio, HDMI HD audio, parallel port, serial ports)
  • PCIe option ROM's are not loaded (for example the ones of RAID/HBA's)

First CSM is enabled and Ubuntu 14.04.1 LTS is installed. The partition table is of type: msdos (MBR) and contains two partitions: ext4 / for linux and a linux swap. A mainline kernel 3.16.0-031600rc6 x86_64 is installed, running with boot parameters: ro rootdelay=180 debug ignore_loglevel crashkernel=384M-:128M. Plymouth is enabled. The networking configuration is set to auto (DHCP).

Measurement

The boot performance measured is a "cold boot": from flipping the power switch until the text tty1 ubuntu login appears on screen. As the firmware already has a setting called "fast boot" to speed the process up, the difference with this setting disabled and enabled are measured too. The measurement was done with an iPhone4 29.9fps movie that was clipped in iPhoto.

Normal variation

Enabled debugging result in a console output for init: plymouth-upstart-bridge main process ended immediately after ubuntu login prompt appears. The variation in that debug message appearing for cold BIOS boots are:

  1. 5.547 seconds
  2. 5.151 seconds
  3. 5.420 seconds
  4. 5.008 seconds
  5. 5.084 seconds
  6. 5.188 seconds

In other words the variation in linux kernel + ubuntu boot process is within a 0.539 seconds range, and has an average value of 5.233 seconds.

During cold UEFI boot the linux kernel + ubuntu boot part were timed by debug output at:

  1. 5.407 seconds
  2. 5.129 seconds
  3. 5.143 seconds
  4. 5.055 seconds
  5. 5.621 seconds
  6. 4.956 seconds

Variation is 0.665 seconds and average is 5.219 seconds.

Community
  • 1
Pro Backup
  • 4,924
  • A better test would have been to change DHCP to static networking to not measure variations in time required for the DHCP address assignment. Changing DHCP to static makes the login prompt appear 2 seconds earlier. – Pro Backup Aug 24 '14 at 21:47
  • what is "BIOS + FAST BOOT"? what does that mean. In my experience the fast-boot options usually have to do with a GOP video card - which does not happen with CSM. Did you try this with GPT? How did you boot the UEFI clean without an ESP? It would have to invoke the CSM to do real-mode disk-calls, wouldn't it? – mikeserv Aug 27 '14 at 02:50
  • @mikeserv The AsRock UEFI setup utility uses different terminology. Fast boot only disables some USB devices during devices. The GOP video card boot is named "Ultra Fast". I have updated the answer to better reflect this different. I don't understand the nature of your question regarding "boot the UEFI clean without an ESP". As far as I know an UEFI boot requires an ESP, and that is how I booted each "UEFI" and "UEFI stub" measurement. Could you please elaborate? – Pro Backup Aug 27 '14 at 12:04
  • I noticed the edit, which I appreciate, but, sadly, I've already upvoted it and cannot do so again. But how do you have an ESP partition on an MBR formatted disk? I don't understand how that works. As far as I know a disk must be formatted with a GPT partition table in order to support the ESP partition flag. I like that you linked to Rod Smith's stuff though. I've done so myself on many occasions. – mikeserv Aug 27 '14 at 12:15
  • @mikeserv The UEFI specification do specify the GPT partition table format, but not as must. Not all firmware handles MBR formatted drives well. That is why many of these tutorials - incorrectly - state that the partition must be GPT formatted. The Asrock AMI firmware does handle MBR formatted partitions well for UEFI boot. The MBR partition type id for EFI is ef. There is also a misunderstanding that existing BIOS boot installs can't be converted to EUFI boot: http://askubuntu.com/questions/509423/which-commands-to-convert-a-ubuntu-bios-install-to-efi-uefi-without-boot-repair – Pro Backup Aug 27 '14 at 13:58
  • Yes, UEFI definitely does specify GPT, though, as is news to me, it also appears it specifies support for an MBR ESP as well. All UEFI firmware is specified to handle GPT disks correctly - that's standard. And it is a simple matter to convert a Linux BIOS install - it's just the kernel for which support is already compiled in in most cases, and that's probably already there. grub is worse than useless in my own opinion on a UEFI booted machine. Windows is another matter, though it is possible. – mikeserv Aug 27 '14 at 14:07
  • @mikeserv In the current state of (kernel?) being unable to write/update the OsIndications EFI variable (http://unix.stackexchange.com/questions/152144/how-to-write-edit-update-the-osindications-efi-variable-from-command-line), there is one useful case for the grub boot menu: to enter the UEFI firmware setup utility on next boot. – Pro Backup Aug 27 '14 at 14:52
  • You don't have an EFI shell? You can get one - you stick it on your ESP and you boot to it. You can write to any var you like in there - in the main. You can also load UEFI drivers and run UEFI applications - like the linux EFI-stub loader. You should probably also get the efibootmgr package. And I really recommend you ditch grub - do rEFInd. Check that link I provided before. I also touch on efibootmgr here. There are several means of getting deeper into there. The efi-tools package is the first step. And of course there is OVMF. – mikeserv Aug 27 '14 at 15:30
  • @mikeserv I am already using efibootmgr and grub as a back-up route. I don't want an EFI shell because that doesn't run through SSH. And I don't need an EFI shell to write any efi var as Fedora 17 - 2 years ago already - was able to write to the efivars using a command like: cat file.bin > /sys/firmware/efi/vars/new_var according to https://ask.fedoraproject.org/en/question/8264/after-installing-fedora-i-cant-open-biosefi-setup/?answer=16402#post-id-16402 – Pro Backup Aug 27 '14 at 16:38
  • I'm sorry - I'm not very familiar with fedora. You can just cat one in? What about UTF-16? The efivar program does have an option for packing a file into a sysvar - but I've never tried. And yeah, you can't do ssh in the EFI shell - it's a pretty sad shell in almost every way, really. But it is good to have on the ESP for worst case scenarios. – mikeserv Aug 27 '14 at 16:46