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.)

You should vote to close this question. Then users will be redirected to the original question and add more answers. SInce that one hasn't been marked as answered yet.
– ppumkinMar 26 '14 at 16:05

I'm just thinking that this one has plenty of activity (views are obviously not as high, simply because this one is less than a day old), more votes, & more answers, so I thought it might be better to leave this one up, and then possibly move your answer over here. It's really a matter of convenience I think. 1 user moving his answer over as opposed to 3 moving their's and thus loosing all votes, conversation and the like. Is there any reason why we should go one way or the other? I don't mind, I'm just thinking that the other people who answered may not want to move, and thus we lose content
– RPi AwesomenessMar 26 '14 at 21:11

@ppumkin Check out this Meta.SE post regarding the closure of dupes: Do Not delete good duplicates and this SE blog post. I think they agrees with my previous point. Unless the duplicate is a copy-paste of the other one, or terrible quality, and because this one has plenty of answers/activity, we should just leave them both open.
– RPi AwesomenessMar 26 '14 at 21:13

1

@ppumkin Good points, so long as this one isn't deleted. I originally reviewed Leave Open, but I guess marking this as a duplicate of that is the right way to go. Only thing I can think of is that I at least want to have an higher-quality Q/A on the marked original, than on the duplicate. That is definitely not the case here.
– RPi AwesomenessMar 27 '14 at 20:08

1

Yea, you are right. There are more answers here. Seems to have got more attention. I suppose we need to leave it to the moderators to decide as they will know better what to do here. Anyway. Well done with getting allot of votes on your answer :) I am sure the OP appreciates your contribution. +1
– ppumkinMar 27 '14 at 20:15

8 Answers
8

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

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.

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.

SD card "class" is a very poor indicator of performance in an embedded system. The "class" ratings are for large sequential file transfers (like you have with a multi-megapixel digital camera), not for small files such as startup scripts. Class 4 cards regularly outperform most Class 10 cards on 4k read and write operations by a factor of 100 or more. There are Class 10 cards with good IOPS, but those models are few and far between.
– Ben VoigtMar 26 '14 at 15:24

Yea I agree with @BenVoigt - when i Used class 4 it seemed like small writes and updates were fast but yea large transfers on class 10 are much better. I wish I could use a RAM card powered by battery for instant performance.
– ppumkinMar 26 '14 at 16:07

I'm sorry, I didn't know that. I shall fix that immediately. I had understood that the higher the class the higher the speed. Thanks for pointing that out, I just learned something :D Thanks for the upvotes too :)
– RPi AwesomenessMar 26 '14 at 18:12

I'm wondering why my answer got downvoted. I don't entirely mind the loss of rep, I just want to know what merited the downvote, so I can improve my answer.
– RPi AwesomenessMar 29 '14 at 18:59

@goldilocks, you can use systemd on raspbian too. It halved the boot time for me.
– John La RooyApr 2 '14 at 13:43

@JohnLaRooy Good to know. I was assuming the performance difference vs. traditional init would mostly be because systemd can parallelize, but it probably also saves time by not having to fork and interpret shell scripts for everything.
– goldilocks♦Apr 2 '14 at 14:55

@goldilocks I don't agree, I tried, and systemd makes much difference, compared to sysvinit. See my answer.
– BasjMay 30 '15 at 12:53

@Basj Even better to know. I've deleted my comment about it probably not making "much difference in terms of boot times since it is [on] a single core". I do mostly use systemd -- but TBH I do not pay much attention to boot times.
– goldilocks♦May 30 '15 at 13:08

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:

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.

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.

To add to this, to compile a statically linked kernel you just need to go through 'make menuconfig' or 'make xconfig' and include the drivers you need in the kernel, instead of selecting them as modules. Doing so cooks them into vmlinuz, and lets you skip the modprobe sequence on bootup, which takes a considerable amount of time to detect and load kernel modules as they are needed.
– Drunken Code MonkeyJun 19 '16 at 5:05

Thank you for your answer. For it to be useful, could you include a few reproducible steps to have it working? (Something like 1) Do this in command line, 2) Do this and this 3) Modify this and this in config.txt 4) Boot, it will take 3.2 seconds! 5) Here is the result of my benchmarks: ...)
– BasjJul 31 at 17:00

Not really, recompiling a kernel is not a 5 steps simple process. There are plenty of how-to's on the web to show you how to configure and compile a Linux kernel...
– Drunken Code MonkeyJul 31 at 17:35

Thank you for your answer. Could you include a few reproducible steps to have it working? (Something like 1) Download an image here: +link 2) Flash it on your microSD 3) Modify this and this in config.txt 4) Boot, it will take 3.2 seconds!)
– BasjJul 31 at 16:59

Answers on this site should include the steps needed to perform the suggested actions (how to determine what modules are loaded, which are needed and how to remove them), and references and links to further information.
– Steve RobillardApr 2 '14 at 23:40