27

I'm creating an embeddable remote application that won't be permanently switched on. I've been playing around with different OS distributions and can reduce the time to boot substantially by using better SD cards with faster read speeds. I'm not fixed to any particular distribution, so I can strip down as much as neccessary to use a minimal Linux distribution.

(I've attempted to look for benchmarks that people have ran to improve boot time, but I haven't found anything with hard figures.)

I could also use build root (see also YouTube video Raspberry Pi - Super Fast Boot Time - Marshmallow Entertainment System)...

Peter Mortensen
  • 2,004
  • 2
  • 15
  • 18
Layke
  • 373
  • 1
  • 3
  • 7

8 Answers8

14

If you combine Arch Linux with the features that Fred suggested, you should get a generally fast booting OS.

What slows down OS' boot-times is

  1. Slow read/write (I/O) speeds.

    So you using a faster SD card will help, a Class 10 card will be substantially faster than a Class 4 card. I misunderstood how SD card classes worked, and that has been pointed out quite clearly in the comments, my bad. Actually, a Class 10 card will be faster than a Class 4 card for large file transfers such as HD video and whatnot. Apparently Class 4 performs just as well with smaller files. Again, my bad, but hey, we all learn now and again.

  2. A bogged-down init sequence.

    If you have lots of software that fires up during the boot phase, the boot-time is going to be slower. More software starting == Longer boot time.

    Thus, if you need a fast boot, cut as much software from the init sequence as possible. You can create a simple script (or I'm sure there is one out there) that will launch software after the main boot sequence completes, spreading the load out a bit more.

That's basically it. Arch Linux is probably the way to go, combined with the features Fred mentioned, as I said before. Arch is a very minimal OS and may not be the best thing for a beginner to use, but if you have experience in Linux, then go for it. It just takes a bit of setting up, as it comes with the bare minimum to install and that's it.

Hope your project goes well!

RPiAwesomeness
  • 3,021
  • 4
  • 31
  • 52
8

I suggest using Arch Linux.

I get normal booting time of 5s (kernel) + 5s (to userspace) and it doesn't require much effort, because it is using systemd for init.

10robinho
  • 726
  • 8
  • 17
8

I wrote an article here about it.

In short: use systemd.

You can easily get your RaspberryPi app running less than 8 seconds after you plugged the power cord, or less than 3 seconds after the Linux boot has started.

An example here, my service is called samplerbox.service:

enter image description here

Note: I haven't tried to optimize userspace time because I don't need it: my app starts early anyway, so I don't mind if the networking DHCP / IP attribution takes 8 seconds after my app has been launched.

Basj
  • 800
  • 3
  • 21
  • 49
5

The optimal solution is probably to build a distribution that does only exactly what you want it to on boot, this way you're guaranteed minimal times (using a minimalist init system like sinit). Alternatively, you might consider using the suspend to disk (hibernation) feature of the Linux kernel. Once booted, the suspend and resume operations later on are pretty quick, and the system is entirely off in the meantime.

Fred
  • 4,592
  • 19
  • 29
3

Using a statically linked kernel instead of modprobing drivers can also dramatically increase performance. There are other optimizations to be made by carefully configuring and recompiling a kernel.

1

Use TinyCoreLinux. It's made for fast loading and to survive power failures.

avra
  • 1,273
  • 8
  • 9
0

You could try to use eINIT to speed up the boot process: : http://sourceforge.net/projects/einit/

Unfortunately at present (Oct 2016) the eINIT homepage notes:

eINIT used to be an alternate implementation of the /sbin/init programme for Linux and FreeBSD. Well, I suppose it still is, but the project has been on hold for years now.

goldilocks
  • 60,325
  • 17
  • 117
  • 234
user13783
  • 9
  • 1
-3

Remove any kernel modules that you won't use.

mrpi64
  • 1