[doug]

I've got a raspberry pi 2 with OpenELEC in my van which holds my daughter's video collection and also my music. I haven't connected a battery to it to keep the pi running when the van is off and don't plan to, so I've been looking for ways to reduce the boot time so my music is accessible quickly. Here's a summary of what I've done and the relative benefits of each step. The steps are in the order of decreasing returns, so the ones at the top are easy/beneficial and the ones at the bottom are harder or have less benefits in decreasing boot time. Any suggestions are welcome.

Note: all times are measured using the stopwatch on my phone. I'll estimate a margin of error of about +/-0.5 seconds. Times are from when I power up to when the kodi menu appears.

1. Edit for RPi2. I now have a RPi2 to replace the old B+ for my van. This cut 2.5s off my previous best boot time (15.5 seconds).
   
2. Next is overclocking
   After installing a brand new OE 4.1.2, booting up, and letting it "settle" for a couple minutes, I shutdown and did a fresh boot. It took almost 37 seconds. That's not too surprising given it wasn't overclocked. We all know the benefits of overclocking for a faster GUI; boot speeds also benefit. Here's a summary of my results:
   No overclock - 37s
   "1000,500,500,6" - 28s
   "1100,600,600,8" - 24.5s
   "1125,600,600,8" - 23.25s - note, this wasn't stable for me, so I backed off to 1100 for the CPU overclock. It's for reference only of the incremental benefit.
   
   lrusak gave a tip to set force_turbo=1 in config.txt (possibly voiding your warranty depending on your overclock). This keeps the RPi at the maximum overclock all the time, rather than allowing the governer to throttle it back sometimes. That setting didn't directly decrease my boot time, but it did allow me to increase my overclock a little which lead to a faster boot
   
   So it's easy to get a faster boot with some overclocking. Use a quality power supply so you can get the highest overclock possible.
   
   
3. Use a fast SD card.
   This is pretty obvious. If your card is fast you'll get faster boots. I am using the NOOBS card that I ordered when I bought the B+. As posted elsewhere in these forums, it's got pretty good 4k random read and write speeds and that is what matters. For the cost, it's very good. There are faster cards or USB3 flash drives at a higher price, but those aren't for me.
   
   
4. add "noram" to cmdline.txt
   I was surprised by this one. I stumbled on this setting in another post and thought I'd give it a try. It dropped my boot time by about 3.5 seconds. Without the option, all of OpenELEC is loaded into RAM. With the noram option, some components are loaded as needed.
   
   
5. Compile OE and turn off many of the options
   This is harder for some, but it's a good learning experience. I know as just a short time ago I didn't know how to use a compiler. I started compiling my own OE because I wanted pyserial included for my bedroom HTPC so I could send serial commands via python to my TV (I couldn't get hex serial commands working in bash...but that's another story). Back to this, I basically removed almost every option I could from the OpenELEC.tv/projects/RPi/options. The result is that my SYSTEM file is 69.7MB instead of 98.3MB. My kernel.img is marginally smaller too. The end result was about 4 seconds shaved off the boot time. (Note: this test was done without the noram option enabled. Because some features are no longer present in this cut-down version, I suspect the benefit of noram is reduced somewhat...but I haven't measured it)
   
   
6. Use the deadline scheduler
   This is another tip from lrusak. I'm not sure of what's going on with this "under the hood" but it leads to a small decrease in boot time. To change it:
   Code:

   nano /storage/.config/udev.rules.d/80-io-scheduler.rules
   and add the following on one line:
   
   Code:

   ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
   
   
7. Disable Services
   In my custom version, I've removed SSH, but left in Samba. I saw somewhat faster boot times (~1s) by disabling these in System->OpenELEC->Services in a stock OE install.
   
   
8. Misc.
   Smaller returns here, but I've also done these things:
   • (splash)false(/splash) in advancedsettings.xml Note: I've changed < to ( and > to ) as tapatalk seems to have issues displaying them.
     
   • use (loglevel)-1(/loglevel) in advancedsettings.xml Note: as above.
     
   • I've created a cutdown Confluence. I only use music and videos so I cut out a lot of stuff related to Weather, Pictures, LiveTV, TV Shows, Addons, and Programs.
     
   • I've set kodi to boot directly to Music as I use that most.
     

One more thing to try:
I've seen some SSD optimization recommendations that include using tmpfs for logging. So, if I can't disable logging in OE, perhaps adding the following to fstab:

Code:

tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

would yield some benefit.

I hope this helps any others using Raspberry Pis for their car PC and hope I get a few suggestions back too.

[lrusak]

You could try the deadline scheduler. This will require a udev rule, similar to this, https://github.com/lrusak/OpenELEC.tv/co...52ba3136d5

Also, if you want a better method of timing, you can use the include systemd-analyze function, however, this requires you to enable ssh.

Code:

OpenELEC:~ # systemd-analyze time
Startup finished in 4.469s (kernel) + 6.095s (userspace) = 10.565s

or do something like this for a more visual representation.

Code:

systemd-analyze plot > /storage/screenshots/OpenELEC-boot-`date +"%Y%m%d-%H%M%S"`.svg

https://www.dropbox.com/s/wt3h934mween7k...213653.png

From this plot you can see that one way to speed it up is to remove the samba server as this slows down the critical chain.

EDIT: OE includes deadline in RPi builds

seems deadline provides some improvement

Code:

Startup finished in 3.147s (kernel) + 6.140s (userspace) = 9.288s

[doug]

I'll look into that, but it's a bit beyond my knowledge level atm and I'm to sleepy to google/learn right now.

Code:

Startup finished in 3.147s (kernel) + 6.140s (userspace) = 9.288s

Wow! Is that the time for the xbmc to fully boot? Is that a Sandisk Extreme or SSD perhaps?

Edit: The png isn't working for me (with various applications). I'm getting a header error.

[lrusak]

I'll look into that, but it's a bit beyond my knowledge level atm and I'm to sleepy to google/learn right now.

Here is how to change the scheduler. (using SSH)

Code:

nano /storage/.config/udev.rules.d/80-io-scheduler.rules

then paste in

Code:

ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Make sure it is all on one line.

Code:

Startup finished in 3.147s (kernel) + 6.140s (userspace) = 9.288s

Wow! Is that the time for the xbmc to fully boot? Is that a Sandisk Extreme or SSD perhaps?

Edit: The png isn't working for me (with various applications). I'm getting a header error.

Nah, just a some normal sandisk card.
This is my overclock

Code:

arm_freq=1150
core_freq=575
sdram_freq=600
over_voltage=6

I also have force_turbo=1 set

This time is until everything starts, so XBMC is started, but it may appear a bit quicker then your visual timing.

Doh, the image is actually an SVG, I'll update my other post to reflect. I have now converted it to a png, so here is the new link.
https://www.dropbox.com/s/wt3h934mween7k...213653.png

[doug]

[
Here is how to change the scheduler. (using SSH)

Code:

nano /storage/.config/udev.rules.d/80-io-scheduler.rules

then paste in

Code:

ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Make sure it is all on one line.

Thanks! Easier than expected.

Nah, just a some normal sandisk card.
This is my overclock

Code:

arm_freq=1150
core_freq=575
sdram_freq=600
over_voltage=6

I also have force_turbo=1 set

That will boot a bit faster with that overclock...I'll try force_turbo=1 too...I've already voided my warranty on my other Pi! :-)

This time is until everything starts, so XBMC is started, but it may appear a bit quicker then your visual timing.

I guess that's true. I'm not sure how much time the bootloader takes...that might not be in your timing, but is in mine.

Doh, the image is actually an SVG, I'll update my other post to reflect. I have now converted it to a png, so here is the new link.
https://www.dropbox.com/s/wt3h934mween7k...213653.png

That graph is interesting I'll have to try that with an SSH enabled build. I usually disable Samba in OE settings and only enable it when my daughter is watching a video and I want to access the music via my phone. There are a few services in there I can look at pulling out.

Fun stuff!

[doug]

A follow up on this. I've done a bit more playing around. I've found there is a big difference between what systemd-analyze states as the boot time and how long it take for an xbmc menu to appear. I put a stock 4.1.2 back on the SD card and got a 20.5 second boot. But systemd-analyze states it's:

Code:

OpenELEC:~ # systemd-analyze time
Startup finished in 3.672s (kernel) + 6.148s (userspace) = 9.820s

So, with standard OE 4.1.2, it takes roughly 10 more seconds for xbmc to boot into a usable state than what systemd reports.

Adding

Code:

ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

to /storage/.config/udev.rules.d/80-io-scheduler.rules made about a half second difference on systemd:

Code:

OpenELEC:~ # systemd-analyze time
Startup finished in 3.297s (kernel) + 6.057s (userspace) = 9.354s

xbmc boot time didn't quite see the full half second reduction, but did boot a bit faster.

Changing force_turbo=1 in config.txt didn't realize any measurable increase in boot time to the xbmc menu. With systemd-analyze, boot time actually increased a bit:

Code:

OpenELEC:~ # systemd-analyze time
Startup finished in 3.402s (kernel) + 6.061s (userspace) = 9.463s

I repeated this to make sure it wasn't an anomaly.

Setting force_turbo did, however, allow me to increase my overclock just slightly (to 1125). With that and using a cut-down OE, I boot to the xbmc menu in 15.5 seconds! And systemd-analyze reports a wickedly fast:

Code:

OpenELEC:~ # systemd-analyze time
Startup finished in 3.228s (kernel) + 4.286s (userspace) = 7.514s

Thanks for those tips...I'm going to update the original post.

[lrusak]

Doug, I may have found something else, but have only done limited testing.

I've compiled OpenELEC with the BFS cpu scheduler patch. It seems to have an improvement from what I can tell.

The only other thing I have done since last time is changed the kernel compression to lz4 (this requires creating an lz4 package and compiling it for the host system).

Code:

OpenELEC:~ # systemd-analyze time
Startup finished in 3.022s (kernel) + 4.777s (userspace) = 7.799s

Here is the plot
http://i.imgur.com/9P7RE7i.png

To do this you just need to run the following command from you openelec build folder.

Code:

wget http://ck.kolivas.org/patches/bfs/3.0/3.16/3.16-sched-bfs-450.patch -O packages/linux/patches/3.16.1/linux-020-bfs-scheduler.patch

Then,

Code:

PROJECT=RPi ARCH=arm ./scripts/clean linux
PROJECT=RPi ARCH=arm ./scripts/unpack linux
cd build.OpenELEC-RPi.arm-devel/linux-3.16.1
make oldconfig

Hit "Y" when it prompts you

Code:

cd ../..
cp build.OpenELEC-RPi.arm-devel/linux-3.16.1/.config projects/RPi/linux/linux.arm.conf

Then finally,

Code:

PROJECT=RPi ARCH=arm ./scripts/clean linux
PROJECT=RPi ARCH=arm ./scripts/build linux

and proof

Code:

OpenELEC:~ # dmesg | grep BFS
[    1.577937] BFS CPU scheduler v0.450 by Con Kolivas.

[doug]

Cool! I'll give that a try tonight!

[doug]

I just tried it and can say it's definitely faster. I can see about a 1/2 second faster boot. I've actually added a few things back into my build of OE that I didn't have before (like wireless drivers). My boot was taking just over 17 seconds and with BFS it is now 16.5s. Nice!

Here is systemd-analyze time (samba disabled; ssh and wired internet enabled)

Code:

xbmc-van:~ # systemd-analyze time
Startup finished in 3.127s (kernel) + 4.736s (userspace) = 7.863s

Looking at the graph of your boot times...ttyAMA0 is taking a half second to load; could it be disabled if it's not used?

[MrMC]

hahahaha, davilla likes that quote

[lrusak]

Looking at the graph of your boot times...ttyAMA0 is taking a half second to load; could it be disabled if it's not used?

I'm not sure where you see that. If you look at the graph anything that is highlighted red means it is part of the critical chain and thus may be holding something up. ttyAMA0 isn't highlighted at all.

Something else I just tried was another udev rule, it can be used in the same file as the other.

/storage/.config/udev.rules.d/80-io-scheduler.rules

Code:

ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/read_ahead_kb}="512"

This made a pretty decent gain.

Code:

Startup finished in 2.538s (kernel) + 4.424s (userspace) = 6.962s

I have also overclocked to the max.

Code:

arm_freq=1200
core_freq=600
sdram_freq=600
over_voltage=8

[doug]

I'll try that too. That's a pretty big jump. I can't get that high of an overclock from my Pi/power supply.

I was reading the graph incorrectly! I'll take a look at that for my boot and try to eliminate some critical path items.

[doug]

I tried the same overclock (possibly/probably unstable for me) and the udev rule. Definitely faster:

Code:

Startup finished in 3.011s (kernel) + 4.529s (userspace) = 7.540s

It's interesting that your kernel loaded 1/2 second faster with those changes and mine was mostly unaffected.

I'm curious if you also have a car/van install and are trying to get the fastest boot or are just trying to optimize it as much as possible for inclusion in OE?

[lrusak]

It's interesting that your kernel loaded 1/2 second faster with those changes and mine was mostly unaffected.

Seems like it takes about ~0.5s longer from a cold boot. For me this means physically plugging in the power.

Code:

Startup finished in 3.156s (kernel) + 4.453s (userspace) = 7.609s

Compared to simply issuing "reboot" from ssh

Code:

Startup finished in 2.506s (kernel) + 4.340s (userspace) = 6.847s

Oh well.

I'm curious if you also have a car/van install and are trying to get the fastest boot or are just trying to optimize it as much as possible for inclusion in OE?

Just for fun I've considered making a car installation, but I really have no use for it right now as I don't have anyone that sits in the backseats of my car. I would like to make a touchscreen music controller, but the subsonic music addon doesn't allow caching like the subsonic app for android does.

[goundoulf]

I have done some tests:

OpenELEC 4.2.1 with Wolfson patches :

Code:

# systemd-analyze time
Startup finished in 7.297s (kernel) + 33.856s (userspace) = 41.154s

Then with: disable_splash=1

Code:

# systemd-analyze time
Startup finished in 7.296s (kernel) + 33.717s (userspace) = 41.013s

Then with: hdmi_edid_file=1

Code:

# systemd-analyze time
Startup finished in 7.298s (kernel) + 33.802s (userspace) = 41.100s

Then with: noram in cmdline.txt

Code:

# systemd-analyze time
Startup finished in 7.295s (kernel) + 33.663s (userspace) = 40.959s

Then with manual net instead of dhcp

Code:

# systemd-analyze time
Startup finished in 7.296s (kernel) + 33.827s (userspace) = 41.123s

Then remove "sleep 25" in the following file:

Code:

# cat .config/autostart.sh
#!/bin/sh
sleep 25
mount -t nfs 192.168.1.10:/mnt/HD/HD_a2/ /storage/dns320 -o udp,noatime,rsize=32768,wsize=32768,nolock

Code:

# systemd-analyze time
Startup finished in 7.306s (kernel) + 9.124s (userspace) = 16.430s

Obviously the nfs mount did not work

Then with: hdmi_group=1, hdmi_mode=16

Code:

# systemd-analyze time
Startup finished in 7.295s (kernel) + 9.117s (userspace) = 16.412s

I noticed with "systemd-analyze blame" the following:

Code:

3.471s connman.service
761ms wpa_supplicant.service
553ms show-version.service

wpa_supplicant could be disabled if not needed. As for show-version.service, is it really needed? And do we need connman.service with a fixed IP address? This would shave nearly 5 seconds for just those 3 services