LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 10-01-2015, 02:43 AM   #1
Feliks
Member
 
Registered: Sep 2015
Location: Big Island ;)
Distribution: Arch, Anything I can get my hands on in a VM (;
Posts: 53

Rep: Reputation: Disabled
Question Arch UEFI loading pretty slow in Virtualbox?


Just curious as I'm planning to put Arch Linux on a UEFI Triple boot system soon, but the loading times are pretty dang slow testing it through Virtualbox. Is this because of the Virtualbox (can I expect good, faster speeds when I actually install it to my triple boot system) or is Arch unusually slow for UEFI? (Which I'm pretty sure is supposed to be faster than BIOS to start with)
 
Old 10-01-2015, 03:21 AM   #2
Head_on_a_Stick
Senior Member
 
Registered: Dec 2014
Location: London, England
Distribution: Debian stable (and OpenBSD-current)
Posts: 1,187

Rep: Reputation: 285Reputation: 285Reputation: 285
I can boot my Arch systems in either UEFI or "BIOS" mode and the time appears to be identical for both methods (as reported by `systemd-analyze`).

The only difference is that the non-UEFI bootup usually involves a manufacturer splash screen for the firmware which may take a second or so to disappear.
 
Old 10-02-2015, 01:54 PM   #3
Feliks
Member
 
Registered: Sep 2015
Location: Big Island ;)
Distribution: Arch, Anything I can get my hands on in a VM (;
Posts: 53

Original Poster
Rep: Reputation: Disabled
Thank you. How are the times compared to debian?
 
Old 10-03-2015, 10:54 AM   #4
Head_on_a_Stick
Senior Member
 
Registered: Dec 2014
Location: London, England
Distribution: Debian stable (and OpenBSD-current)
Posts: 1,187

Rep: Reputation: 285Reputation: 285Reputation: 285
Quote:
Originally Posted by Feliks View Post
How are the times compared to debian?
Interestingly, Debian is consistently faster (~4.0 seconds vs. ~4.3 seconds).
 
Old 10-10-2015, 07:09 PM   #5
Feliks
Member
 
Registered: Sep 2015
Location: Big Island ;)
Distribution: Arch, Anything I can get my hands on in a VM (;
Posts: 53

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Head_on_a_Stick View Post
Interestingly, Debian is consistently faster (~4.0 seconds vs. ~4.3 seconds).
That is interesting. I would think Arch ought to be faster, being more minimalistic & such. Is it noticeable faster then or only if you're looking for it?
 
Old 10-11-2015, 11:26 AM   #6
Head_on_a_Stick
Senior Member
 
Registered: Dec 2014
Location: London, England
Distribution: Debian stable (and OpenBSD-current)
Posts: 1,187

Rep: Reputation: 285Reputation: 285Reputation: 285
Quote:
Originally Posted by Feliks View Post
Is it noticeable faster then or only if you're looking for it?
It's very close indeed and not at all noticeable.

That was from an old system that I managed to hose (botched btrfs conversion).

I have a new dual-boot Arch [testing]/Debian jessie set up now.

Here is the jessie time:
Code:
empty@jessie ~ % systemd-analyze 
Startup finished in 3.019s (kernel) + 1.619s (userspace) = 4.639s
empty@jessie ~ % systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.616s
└─multi-user.target @1.616s
  └─nftables.service @346ms +1.270s
    └─basic.target @345ms
      └─timers.target @344ms
        └─systemd-tmpfiles-clean.timer @344ms
          └─sysinit.target @344ms
            └─systemd-backlight@backlight:intel_backlight.service @1.492s +1ms
              └─system-systemd\x2dbacklight.slice @1.491s
                └─system.slice @74ms
                  └─-.slice @73ms
That's using NetworkManager though -- I will probably switch to systemd-networkd and shave a second off that time.

I'll edit this with my Arch time later...

EDIT: From Arch:
Code:
empty@Arch ~ % systemd-analyze 
Startup finished in 3.762s (firmware) + 429ms (loader) + 2.637s (kernel) + 1.936s (userspace) = 8.765s
empty@Arch ~ % systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.936s
└─multi-user.target @1.936s
  └─systemd-resolved.service @1.905s +30ms
    └─network.target @1.904s
      └─systemd-networkd.service @1.874s +30ms
        └─network-pre.target @1.873s
          └─nftables.service @1.574s +298ms
            └─basic.target @1.571s
              └─sockets.target @1.571s
                └─dbus.socket @1.571s
                  └─sysinit.target @1.571s
                    └─systemd-backlight@backlight:intel_backlight.service @535ms +1.035s
                      └─system-systemd\x2dbacklight.slice @535ms
                        └─system.slice @85ms
                          └─-.slice @81ms
The Arch system is controlling the boot process (with systemd-boot, Secure Boot enabled) so the `systemd-analyze` output shows the firmware & (systemd-boot, née gummiboot) loader times as well.

Just taking the "kernel" & "userspace" times shows a pretty much identical result (but with Debian using the slower NetworkManager.service).

On the stopwatch (ie, including the firmware & loader times for both systems), I can detect no difference between the two.

Last edited by Head_on_a_Stick; 10-11-2015 at 01:50 PM. Reason: Added `critical-chain` output
 
Old 10-11-2015, 05:51 PM   #7
Feliks
Member
 
Registered: Sep 2015
Location: Big Island ;)
Distribution: Arch, Anything I can get my hands on in a VM (;
Posts: 53

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Head_on_a_Stick View Post
It's very close indeed and not at all noticeable.

That was from an old system that I managed to hose (botched btrfs conversion).

I have a new dual-boot Arch [testing]/Debian jessie set up now.

Here is the jessie time:
Code:
empty@jessie ~ % systemd-analyze 
Startup finished in 3.019s (kernel) + 1.619s (userspace) = 4.639s
empty@jessie ~ % systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.616s
└─multi-user.target @1.616s
  └─nftables.service @346ms +1.270s
    └─basic.target @345ms
      └─timers.target @344ms
        └─systemd-tmpfiles-clean.timer @344ms
          └─sysinit.target @344ms
            └─systemd-backlight@backlight:intel_backlight.service @1.492s +1ms
              └─system-systemd\x2dbacklight.slice @1.491s
                └─system.slice @74ms
                  └─-.slice @73ms
That's using NetworkManager though -- I will probably switch to systemd-networkd and shave a second off that time.

I'll edit this with my Arch time later...

EDIT: From Arch:
Code:
empty@Arch ~ % systemd-analyze 
Startup finished in 3.762s (firmware) + 429ms (loader) + 2.637s (kernel) + 1.936s (userspace) = 8.765s
empty@Arch ~ % systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.936s
└─multi-user.target @1.936s
  └─systemd-resolved.service @1.905s +30ms
    └─network.target @1.904s
      └─systemd-networkd.service @1.874s +30ms
        └─network-pre.target @1.873s
          └─nftables.service @1.574s +298ms
            └─basic.target @1.571s
              └─sockets.target @1.571s
                └─dbus.socket @1.571s
                  └─sysinit.target @1.571s
                    └─systemd-backlight@backlight:intel_backlight.service @535ms +1.035s
                      └─system-systemd\x2dbacklight.slice @535ms
                        └─system.slice @85ms
                          └─-.slice @81ms
The Arch system is controlling the boot process (with systemd-boot, Secure Boot enabled) so the `systemd-analyze` output shows the firmware & (systemd-boot, née gummiboot) loader times as well.

Just taking the "kernel" & "userspace" times shows a pretty much identical result (but with Debian using the slower NetworkManager.service).

On the stopwatch (ie, including the firmware & loader times for both systems), I can detect no difference between the two.
That was super informative, haha. Thank you! Cheers.
 
  


Reply

Tags
arch, speed, uefi, virtualbox


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
usb uefi install arch can not acess tty xeveri Arch 2 12-02-2014 01:29 PM
Cannot boot arch iso in uefi mode jbpenguin Arch 1 09-04-2014 08:11 PM
UEFI Arch 64 already installed, using GPT and want windows 7 dualboot justacoupleofquestions Linux - Newbie 1 07-28-2014 12:15 PM
LXer: Simple Image Reducer - Pretty slick, Pretty easy, Pretty light, & Pretty nice. LXer Syndicated Linux News 0 05-14-2013 07:41 AM
LXer: Test-Driving VirtualBox 4.1 on Linux: Bumpy but Pretty Good LXer Syndicated Linux News 0 07-22-2011 09:00 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 10:31 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration