Reduce POST time

Hello.

Looks like hibernation is the only practical way to solve battery draining issues. So, I’m trying to figure out if it’s possible to reduce the time between power on and a moment when an OS is actually ready to resume.

In my case it takes 18 seconds to go from cold laptop to LUKS unlock screen. Given that the actual resume takes 10 seconds more this all seems a bit too much.

In BIOS I’ve enabled quick boot, disabled USB boot and set boot timeout to 0. Other than that I do not see any options that would potentially decrease the POST time. GRUB is also configured with 0 timeout.

I’m using Kubuntu 21.10 and Framework DIY i7 with SN850 and OEM 32GB RAM, BIOS 3.06 (yeah, I know, 3.07, but I’ll wait for fwupdate).

It’s also interesting to me what is happening during initial power-on sequence. After I press power button on a cold laptop it takes ~8 seconds before LED backlight is turned on. I assume this time os occupied by memory test and SDD initialization. Still it looks kinda strange, since even with full POST and non-UEFI boot my older PC booted in a couple of seconds.

Yes, I do understand that. However currently I do not have any active cards installed. Only the passive ones: type-C and type-A.

Also I think that even storage cards would not introduce any substantial latency if BIOS is not configured to boot from USB.

u can achieve faster boot times
with EFISTUB instead of GRUB, as GRUB with LUKS is slow
also, u can switch to a different init like s6 or dinit if thats viable (u’ll have to create service files ur self).
Those r the fastest full blown inits i’ve test so far

1 Like

Oh my! Indeed it does decrease the boot time in ~2 seconds. Still I don’t get how. If I’m not mistaken Type-A is a passive card (just a piece of wire) and should not affect it in any way. :man_shrugging:

Would really love to hear any comments from the Framework team. My guess is port power management and boot probing. But that was disabled in my config.

Interesting. Do you have any estimates on how many seconds would it shave off?

I’m not sure if it’s a fluke or not, but looks like switching GRUB to text mode saves ~5 more seconds.

in /etc/default/grub I did this:

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=console

And then I did update-grub

1 Like

Wow, I didn’t realize the expansion cards actually make a notable impact on boot time! Removing by 2 USB-A expansion cards reduced the firmware boot time by ~2 seconds as well.

This is on Arch (using systemd-boot and nothing else)

Cold boot with 2x USB-A and 2x USB-C

$ systemd-analyze
Startup finished in 6.748s (firmware) + 617ms (loader) + 1.075s (kernel) + 358ms (initrd) + 2.994s (userspace) = 11.794s 
graphical.target reached after 2.994s in userspace

Cold boot with 2x USB-C only

$ systemd-analyze
Startup finished in 4.344s (firmware) + 621ms (loader) + 1.099s (kernel) + 380ms (initrd) + 2.872s (userspace) = 9.319s 
graphical.target reached after 2.872s in userspace
2 Likes

Thanks for systemd-analyze!

Hm… for the same setup I get:

Startup finished in 8.826s (firmware) + 4.521s (loader) + 8.675s (kernel) + 6.470s (userspace) = 28.495s 
graphical.target reached after 6.339s in userspace

Notable differences are the kernel and the loader. The latter is probably because of LUKS, but why the firmware and kernel times are so different? I’m using Kubuntu 21.10 by the way.

  • compared to GRUB opening LUKS with initrd is nearly instant
  • switching init may bring a difference of around 10 sec depending on services
    hardware will always be a factor
2 Likes

The kernel difference is likely because my initrd is pretty small doesn’t really load much and Arch also defaults to using zstd which is also faster to decompress versus gzip.

The firmware difference is strange if you also have the same expansion slots. Maybe the other components are making a difference? The exact spec is shared on my blog (I swapped the microSD with a usb-A since the post). I’m also running the latest bios version 3.07 FWIW.

1 Like