feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Boot time on original Pi

Sun Jun 30, 2019 4:06 pm

I have a Raspberry Pi Model B Rev 2.0. For the vast majority of its life it has lived in a cupboard. About every two years I get it out the cupboard and think about turning it into an internet radio. Normally after I've pondered on how to do this for a bit it gets put back in its cupboard.

I've reached this stage again. I've put the latest buster lite image on an SD card. It's taking a long time to boot though. Easily over 40 seconds, maybe more like a minute. Is this normal? I don't remember it taking so long? I'm having to hold the sd card in place with my hand at the moment as the holder has broken so that maybe not helping.

What is the fastest a console only image can boot on an original pi without spending a stupid amount of time optimising things?

tpylkko
Posts: 381
Joined: Tue Oct 14, 2014 5:21 pm

Re: Boot time on original Pi

Sun Jun 30, 2019 4:40 pm

Why not just use an already exisitng internet radio/music OS image in it like pimusicbox or volumio?

It might be that the first time boot the image it is resizing the partitions or systemd is running an fsck or waiting for a service or device to come up. If this is the case, there would be some message about it in the logs i.e journalctl).

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Sun Jun 30, 2019 5:09 pm

Thanks, but that's not how I want to use it. I want to turn on the old stereo and have the plugged in internet radio respond as soon as possible in case I want to change station while I'm standing up. No remotes, phones, laptops controlling it.

fruitoftheloom
Posts: 20487
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: Boot time on original Pi

Sun Jun 30, 2019 5:13 pm

feelslikeautumn wrote:
Sun Jun 30, 2019 4:06 pm
I have a Raspberry Pi Model B Rev 2.0. For the vast majority of its life it has lived in a cupboard. About every two years I get it out the cupboard and think about turning it into an internet radio. Normally after I've pondered on how to do this for a bit it gets put back in its cupboard.

I've reached this stage again. I've put the latest buster lite image on an SD card. It's taking a long time to boot though. Easily over 40 seconds, maybe more like a minute. Is this normal? I don't remember it taking so long? I'm having to hold the sd card in place with my hand at the moment as the holder has broken so that maybe not helping.

What is the fastest a console only image can boot on an original pi without spending a stupid amount of time optimising things?

PiCore ?

http://forum.tinycorelinux.net/index.ph ... ,57.0.html

https://www.picoreplayer.org/pcp_feature.shtml
Retired disgracefully.....

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Sun Jun 30, 2019 5:20 pm

Again, I'm not interested in distro suggestions. (Though thank you.) I can Google reasonably well. I'm interested in people's actual experiences. I've seen 12 seconds written for a pi zero. Is that achievable?

User avatar
HawaiianPi
Posts: 4534
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: Boot time on original Pi

Sun Jun 30, 2019 5:36 pm

A faster SD card could help as well. The SanDisk Ultra A1 cards are affordable and work much better as an OS drive due to superior random IOPS. And yea, I know, they're micro SD and the old B models take full size, but they do come with a full size SD adapter.
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

hippy
Posts: 5790
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Boot time on original Pi

Sun Jun 30, 2019 6:07 pm

I have just installed Raspbian Buster Desktop Without Recommended Software on a Pi Zero W which is comparable to an original Pi B. The first boot from plugging the PSU in to seeing the waste basket appear on the desktop was 2 minutes 8 seconds.

After initial configuration of Wi-Fi only and a reboot; from the rainbow screen to the waste basket appearing was 1 minute 8 seconds.

Setting boot to CLI with auto-login, and another reboot; from rainbow screen to command prompt was 40 seconds.

I have a couple of Pi B scheduled for installation and I'll report back on those once done; one looks to be a Rev 1 with fuses, the other looks to be a Rev 2.

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Sun Jun 30, 2019 6:20 pm

Thanks hippy that's the kind of thing I was after. It must be my mind playing tricks on me. I knew originally the pi boot was slow, but I was convinced stretch had speeded it up to around 20 seconds. It's been a while.

Will have to get the super glue out to fix the SD card holder.

hippy
Posts: 5790
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Boot time on original Pi

Sun Jun 30, 2019 7:32 pm

Realised I don't need to install, can just boot from the card I am using with the Zero W ...

Code: Select all

Pi B Rev 1 : Desktop 82s - Command prompt 45s
Pi B Rev 2 : Desktop 75s - Command prompt 45s

Pi Zero  W : Desktop 68s - Command prompt 40s

Pi 3B      : Desktop 21s - Command prompt 18s

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Sun Jun 30, 2019 9:54 pm

Thank you again hippy for the detailed results. I've been able to do a few experiments myself tonight.

I make it that buster lite is around 10 seconds slower than stretch on the 1Brev2 (39 v 29). Amazingly my 3B is 25 seconds slower (36 v 11) - much slower than your 3B result.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Boot time on original Pi

Sun Jun 30, 2019 9:58 pm

feelslikeautumn wrote:
Sun Jun 30, 2019 4:06 pm
I have a Raspberry Pi Model B Rev 2.0. For the vast majority of its life it has lived in a cupboard. About every two years I get it out the cupboard and think about turning it into an internet radio. Normally after I've pondered on how to do this for a bit it gets put back in its cupboard.

I've reached this stage again. I've put the latest buster lite image on an SD card. It's taking a long time to boot though. Easily over 40 seconds, maybe more like a minute. Is this normal? I don't remember it taking so long? I'm having to hold the sd card in place with my hand at the moment as the holder has broken so that maybe not helping.

What is the fastest a console only image can boot on an original pi without spending a stupid amount of time optimising things?
For the original RPi you are likely better off using RISC OS, and using one of the Internet Radio streamers for RISC OS. Unfortunately Raspbian has been getting slower on the old BCM2835 Raspberry Pi systems, even though they still sell the BCM2835 systems.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

hippy
Posts: 5790
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Boot time on original Pi

Sun Jun 30, 2019 10:14 pm

feelslikeautumn wrote:
Sun Jun 30, 2019 9:54 pm
I make it that buster lite is around 10 seconds slower than stretch on the 1Brev2 (39 v 29). Amazingly my 3B is 25 seconds slower (36 v 11) - much slower than your 3B result.
The 3B tested was my live machine so I didn't use the same card, just rebooted - I should have noted that; I just sought a comparison. That 'faster than yours' could be because that's a faster card. I do have another 3B so I can try that so it is like with like.

I think I have a download copy of Stretch still lying around so I'll also give that a try when I have some spare moments.

The odd one for me was a B+ which was a little slower to desktop than a B Rev 2 (77s) and slower to command line than both B's (47s). Notably it's 2s slower than Rev 2 for both desktop and command prompt.

Update: Consolidated list so far. I don't have a spare PSU to hand so the 3B test threw up a few low voltage indications which probably leads to throttling and extended time. Roughly same as the one with a proper PSU and what I believe may be a faster card.

Code: Select all

Pi B+      : Desktop 77s - Command prompt 47s

Pi B Rev 1 : Desktop 82s - Command prompt 45s
Pi B Rev 2 : Desktop 75s - Command prompt 45s

Pi Zero  W : Desktop 68s - Command prompt 40s

Pi 3B      : Desktop 25s - Command prompt 20s [1]
Pi 3B      : Desktop 21s - Command prompt 18s [2]

[1] Same card as all above this, some low voltage warnings
[2] Faster card

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Mon Jul 01, 2019 7:28 am

Wow thanks again!

I've worked out now why the 3B was giving a stupidly slow boot for me. I didn't have the ethernet cable plugged in. With it connected the timings are better. Buster lite (16). Stretch lite (11).

Buster lite still noticeably slower even on the 3B.
Last edited by feelslikeautumn on Mon Jul 01, 2019 7:56 am, edited 1 time in total.

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Mon Jul 01, 2019 7:37 am

DavidS wrote:
Sun Jun 30, 2019 9:58 pm
For the original RPi you are likely better off using RISC OS, and using one of the Internet Radio streamers for RISC OS. Unfortunately Raspbian has been getting slower on the old BCM2835 Raspberry Pi systems, even though they still sell the BCM2835 systems.
Thanks David.

I'm very fond of RiscOs from back in the day (although I blame the middle click for my repetitive strain injury). I don't have an objection to using RiscOs except sometime ago I bought a second hand adafruit 2.8inch TFT and a hifi berry clone for this project. Both I think possibly don't work with Risc OS?

It continues to be a wonderful reminder what can be achieved with modest hardware and good programming.

Similarly if somebody can point me at a bare metal internet radio project I would be delighted.

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Mon Jul 01, 2019 7:57 am

Argh! I was reading the wrong numbers. Edited post above.

Buster lite is definitely slower to boot than stretch was.

tqhien
Posts: 35
Joined: Thu Feb 02, 2012 10:07 am

Re: Boot time on original Pi

Mon Jul 01, 2019 1:03 pm

Hello,

I use "Buildroot" to custom build a kernel and boot to my python app, in something like 12 seconds with a RpiZero (6 seconds to boot, a few more for loading my python/pygame graphic app) so I can say that's quite optimized !

The basic buildroot recipe allows a simple boot to Busybox, and then you add what you need (python, wifi, etc)
Then you change linux kernel options to squeeze out some kernel functions not needed to speedup the all thing.

If you need some hint how to do that, tell me.

Hien.

hippy
Posts: 5790
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Boot time on original Pi

Mon Jul 01, 2019 1:19 pm

feelslikeautumn wrote:
Mon Jul 01, 2019 7:57 am
Buster lite is definitely slower to boot than stretch was.
I found a bootable Stretch Lite SD Card which I booted on my B Rev 2. That was installed using PINN so there's a delay while PINN intervenes before continuing to boot Stretch. Booting to the command prompt; 57 seconds for Stretch Lite/PINN against 45 seconds for Buster Full.

The rainbow screen seemed to be there for much longer, with a "cannot access mailbox" error at the start of the boot messages.

I flashed the November 2018 Stretch Lite to the same card and, after initial resizing and boot configuration, the Pi B Rev 2 boot to command prompt takes 45 seconds, same as Buster.

For the Pi 3B that was 40 seconds, again with some low voltage indications as earlier so longer than it could be, almost twice as slow as Buster with the same PSU, almost four times slower than what you are seeing. And even with a decent PSU I'm still getting low voltage indications. Maybe that's something about this particular 3B.

I had thought that none of my tests used a wired connection, so 'no ethernet', though I would expect the 3B uses the Wi-Fi settings I had provided for the Pi Zero W to connect to my router. With the 3B connected by wire it did cut the boot time to 20 seconds, a second time to 30 seconds, and "starting hostname service" looks like it may be a major culprit for delay.

I guess what it all shows is how difficult it is to do comparative testing.

User avatar
RaTTuS
Posts: 10415
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK

Re: Boot time on original Pi

Mon Jul 01, 2019 3:02 pm

my Pi one ...
uname -a; cat /proc/cpuinfo ; df -h

Code: Select all

Linux PiOne 4.19.50+ #896 Thu Jun 20 16:09:52 BST 2019 armv6l GNU/Linux
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7
 
Hardware        : BCM2835
Revision        : 0002
Serial          : 00000000134e058d
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G   14G  821M  95% /
devtmpfs         86M     0   86M   0% /dev
tmpfs            90M     0   90M   0% /dev/shm
tmpfs            90M  3.0M   87M   4% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            90M     0   90M   0% /sys/fs/cgroup
/dev/mmcblk0p1   56M   40M   17M  71% /boot
tmpfs            18M     0   18M   0% /run/user/1001
takes 1 min 10 secs to get to
"Starting Terminate Plymouth Boot Screen" or whatever it says before logging in [mine auto logs into a screen setup ] so is not a clean boot
I may redo a fresh image but meh ....

Code: Select all

uprecords
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
     1   229 days, 23:01:54 | Linux 4.9.41+             Wed Sep 13 17:19:50 2017
     2   140 days, 12:00:55 | Linux 4.14.34+            Mon Jun  4 16:34:21 2018
     3   107 days, 23:51:41 | Linux 4.14.98+            Thu Mar 14 17:29:51 2019
     4    84 days, 09:05:46 | Linux 4.14.79+            Thu Dec 20 08:23:24 2018
     5    58 days, 04:04:13 | Linux 4.14.34+            Tue Oct 23 05:18:30 2018
     6    33 days, 23:40:14 | Linux 4.9.59+             Tue May  1 16:35:32 2018
     7    11 days, 20:21:59 | Linux 4.9.41+             Fri Sep  1 11:34:26 2017
     8     0 days, 20:06:12 | Linux 4.19.42+            Sun Jun 30 18:22:12 2019
     9     0 days, 08:31:32 | Linux 4.9.41+             Wed Sep 13 08:16:52 2017
    10     0 days, 01:25:10 | Linux 4.19.50+            Mon Jul  1 14:28:04 2019
----------------------------+---------------------------------------------------
->  11     0 days, 00:06:42 | Linux 4.19.50+            Mon Jul  1 15:55:11 2019
----------------------------+---------------------------------------------------
1up in     0 days, 01:18:29 | at                        Mon Jul  1 17:20:22 2019
t10 in     0 days, 01:18:29 | at                        Mon Jul  1 17:20:22 2019
no1 in   229 days, 22:55:13 | at                        Sun Feb 16 13:57:06 2020
    up   668 days, 02:16:18 | since                     Fri Sep  1 11:34:26 2017
  down     0 days, 02:11:09 | since                     Fri Sep  1 11:34:26 2017
   %up               99.986 | since                     Fri Sep  1 11:34:26 2017
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Mon Jul 01, 2019 8:44 pm

Thanks all for the replies.

@hippy I used the stretch lite image dated 2018-03-13 since that is the one I already had downloaded. I think the boot waits for dhcp if you don't have ethernet connected (this can be turned off by raspi-config though).

Stretch on 1B:

Code: Select all

~$ systemd-analyze blame
         15.895s dhcpcd.service
          7.311s dev-mmcblk0p2.device
          5.608s networking.service
          3.437s keyboard-setup.service
          3.402s raspi-config.service
          3.046s dphys-swapfile.service
          1.881s systemd-logind.service
          1.651s systemd-journald.service
          1.645s systemd-udev-trigger.service
          1.606s avahi-daemon.service
          1.542s fake-hwclock.service
          1.437s sys-kernel-debug.mount
          1.336s alsa-restore.service
          1.291s run-rpc_pipefs.mount
          1.254s triggerhappy.service
          1.224s kmod-static-nodes.service
          1.206s systemd-udevd.service
          1.178s systemd-fsck-root.service
          1.004s systemd-timesyncd.service
           987ms systemd-modules-load.service
           970ms rsyslog.service
           831ms systemd-tmpfiles-setup.service
           771ms systemd-remount-fs.service
           706ms systemd-sysctl.service
           617ms systemd-update-utmp.service
           607ms wifi-country.service
           573ms [email protected]\x2dpartuuid-c11d6b84\x2d01.service
           533ms [email protected]
           515ms systemd-journal-flush.service
           473ms nfs-config.service
           470ms sys-kernel-config.mount
           444ms systemd-tmpfiles-setup-dev.service
           422ms console-setup.service
           415ms systemd-random-seed.service
           319ms dev-mqueue.mount
           318ms plymouth-read-write.service
           275ms systemd-update-utmp-runlevel.service
           237ms plymouth-start.service
           212ms boot.mount
           207ms systemd-user-sessions.service
           205ms rc-local.service
           188ms plymouth-quit.service
           172ms plymouth-quit-wait.service

~$ 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 @1min 31.920s
└─multi-user.target @1min 31.919s
  └─getty.target @29.904s
    └─[email protected] @29.892s
      └─systemd-user-sessions.service @29.272s +207ms
        └─network.target @29.207s
          └─dhcpcd.service @13.283s +15.895s
            └─basic.target @12.181s
              └─sockets.target @12.180s
                └─dbus.socket @12.179s
                  └─sysinit.target @12.091s
                    └─systemd-timesyncd.service @11.071s +1.004s
                      └─systemd-tmpfiles-setup.service @9.904s +831ms
                        └─local-fs.target @9.730s
                          └─run-user-1000.mount @1min 9.859s
                            └─local-fs-pre.target @6.066s
                              └─keyboard-setup.service @2.238s +3.437s
                                └─system.slice @1.943s
                                  └─-.slice @1.561s
Buster on 1B:

Code: Select all

~$ systemd-analyze blame
         15.117s dhcpcd.service
         10.436s dev-mmcblk0p2.device
          5.049s raspi-config.service
          4.357s wpa_supplicant.service
          3.755s systemd-timesyncd.service
          3.363s systemd-udev-trigger.service
          3.298s networking.service
          3.128s systemd-logind.service
          3.108s dphys-swapfile.service
          2.979s avahi-daemon.service
          2.852s keyboard-setup.service
          2.622s rsyslog.service
          2.491s [email protected]\x2dpartuuid-5be7f3da\x2d01.service
          2.253s dev-mqueue.mount
          2.126s sys-kernel-debug.mount
          2.115s systemd-modules-load.service
          2.091s systemd-journald.service
          2.077s fake-hwclock.service
          2.054s kmod-static-nodes.service
          2.011s rng-tools.service
          1.829s run-rpc_pipefs.mount
          1.463s systemd-update-utmp.service
          1.372s triggerhappy.service
          1.228s systemd-fsck-root.service
          1.151s [email protected]
          1.081s systemd-tmpfiles-setup.service
           838ms systemd-remount-fs.service
           696ms systemd-sysctl.service
           625ms systemd-sysusers.service
           592ms systemd-journal-flush.service
           554ms systemd-random-seed.service
           432ms sys-kernel-config.mount
           415ms console-setup.service
           412ms systemd-udevd.service
           397ms nfs-config.service
           395ms [email protected]
           350ms systemd-user-sessions.service
           279ms systemd-update-utmp-runlevel.service
           271ms alsa-restore.service
           241ms systemd-tmpfiles-setup-dev.service
           170ms boot.mount
           151ms rc-local.service
           125ms ifupdown-pre.service

~$ 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 @1min 33.845s
└─multi-user.target @1min 33.835s
  └─getty.target @39.765s
    └─[email protected] @39.736s
      └─systemd-user-sessions.service @39.285s +350ms
        └─network.target @39.228s
          └─dhcpcd.service @24.080s +15.117s
            └─basic.target @22.894s
              └─sockets.target @22.868s
                └─avahi-daemon.socket @22.841s
                  └─sysinit.target @22.687s
                    └─systemd-timesyncd.service @18.896s +3.755s
                      └─systemd-tmpfiles-setup.service @17.720s +1.081s
                        └─local-fs.target @17.404s
                          └─run-user-1000.mount @53.066s
                            └─local-fs-pre.target @10.082s
                              └─systemd-tmpfiles-setup-dev.service @9.772s +241ms
                                └─systemd-sysusers.service @9.062s +625ms
                                  └─systemd-remount-fs.service @8.137s +838ms
                                    └─systemd-fsck-root.service @6.843s +1.228s
                                      └─fake-hwclock.service @4.393s +2.077s
                                        └─systemd-journald.socket @3.765s
                                          └─system.slice @3.573s
                                            └─-.slice @3.573s
Stretch on 3B:

Code: Select all

~$ systemd-analyze blame
          8.107s dhcpcd.service
          4.651s hciuart.service
          1.360s dev-mmcblk0p2.device
          1.261s raspi-config.service
           670ms dphys-swapfile.service
           587ms keyboard-setup.service
           474ms networking.service
           415ms systemd-logind.service
           391ms wifi-country.service
           384ms systemd-timesyncd.service
           341ms systemd-modules-load.service
           337ms fake-hwclock.service
           330ms alsa-restore.service
           329ms systemd-udev-trigger.service
           317ms [email protected]\x2dpartuuid-c11d6b84\x2d01.service
           291ms rsyslog.service
           283ms avahi-daemon.service
           265ms dev-mqueue.mount
           261ms sys-kernel-debug.mount
           256ms kmod-static-nodes.service
           251ms systemd-fsck-root.service
           248ms plymouth-start.service
           227ms systemd-udevd.service
           177ms systemd-remount-fs.service
           145ms systemd-journald.service
           127ms bluetooth.service
           116ms systemd-tmpfiles-setup.service
           107ms systemd-tmpfiles-setup-dev.service
            87ms [email protected]
            80ms plymouth-read-write.service
            77ms systemd-update-utmp.service
            65ms console-setup.service
            64ms boot.mount
            63ms systemd-journal-flush.service
            63ms systemd-random-seed.service
            54ms systemd-rfkill.service
            53ms nfs-config.service
            47ms triggerhappy.service
            46ms sys-kernel-config.mount
            40ms systemd-sysctl.service
            38ms plymouth-quit.service
            35ms plymouth-quit-wait.service
            33ms systemd-update-utmp-runlevel.service
            31ms systemd-user-sessions.service
            31ms run-rpc_pipefs.mount
            22ms rc-local.service

~$ 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 @11.395s
└─multi-user.target @11.395s
  └─getty.target @11.394s
    └─[email protected] @11.394s
      └─systemd-user-sessions.service @11.310s +31ms
        └─network.target @11.293s
          └─dhcpcd.service @3.183s +8.107s
            └─basic.target @3.139s
              └─sockets.target @3.133s
                └─triggerhappy.socket @3.126s
                  └─sysinit.target @3.099s
                    └─systemd-timesyncd.service @2.713s +384ms
                      └─systemd-tmpfiles-setup.service @2.558s +116ms
                        └─local-fs.target @2.547s
                          └─boot.mount @2.480s +64ms
                            └─[email protected]\x2dpartuuid-c11d6b84\x2d01.service @2.156s +317ms
                              └─dev-disk-by\x2dpartuuid-c11d6b84\x2d01.device @2.118s

Buster on 3B:

Code: Select all

~$ systemd-analyze blame
         10.500s dhcpcd.service
          4.934s hciuart.service
          2.129s dev-mmcblk0p2.device
          1.513s raspi-config.service
           722ms [email protected]\x2dpartuuid-5be7f3da\x2d01.service
           647ms keyboard-setup.service
           613ms systemd-udev-trigger.service
           589ms systemd-timesyncd.service
           478ms wpa_supplicant.service
           460ms sys-kernel-debug.mount
           460ms dphys-swapfile.service
           448ms kmod-static-nodes.service
           421ms avahi-daemon.service
           421ms systemd-logind.service
           369ms networking.service
           364ms systemd-modules-load.service
           345ms dev-mqueue.mount
           309ms [email protected]
           287ms rsyslog.service
           241ms systemd-fsck-root.service
           229ms systemd-journald.service
           218ms triggerhappy.service
           212ms fake-hwclock.service
           188ms systemd-remount-fs.service
           180ms run-rpc_pipefs.mount
           173ms systemd-udevd.service
           160ms systemd-journal-flush.service
           158ms alsa-restore.service
           155ms systemd-sysctl.service
           143ms bluetooth.service
           137ms systemd-tmpfiles-setup.service
           123ms rng-tools.service
           113ms systemd-update-utmp.service
           107ms systemd-sysusers.service
            85ms systemd-random-seed.service
            84ms sys-kernel-config.mount
            84ms systemd-tmpfiles-setup-dev.service
            58ms console-setup.service
            55ms systemd-user-sessions.service
            54ms nfs-config.service
            52ms systemd-update-utmp-runlevel.service
            43ms boot.mount
            43ms [email protected]
            39ms rc-local.service
            29ms systemd-rfkill.service
            28ms ifupdown-pre.service

~$ 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 @16.119s
└─multi-user.target @16.114s
  └─getty.target @16.109s
    └─[email protected] @16.103s
      └─systemd-user-sessions.service @16.037s +55ms
        └─network.target @16.003s
          └─dhcpcd.service @5.490s +10.500s
            └─basic.target @5.242s
              └─sockets.target @5.234s
                └─avahi-daemon.socket @5.226s
                  └─sysinit.target @5.167s
                    └─systemd-timesyncd.service @4.560s +589ms
                      └─systemd-tmpfiles-setup.service @4.404s +137ms
                        └─local-fs.target @4.389s
                          └─boot.mount @4.336s +43ms
                            └─[email protected]\x2dpartuuid-5be7f3da\x2d01.service @3.415s +722ms
                              └─dev-disk-by\x2dpartuuid-5be7f3da\x2d01.device @3.398s


@Hien Really interesting to read about the speed of your buildroot. I've thought about doing something like this. I may have some follow up questions for you! Do you know of a good online tutorial that is based around the pi?

tqhien
Posts: 35
Joined: Thu Feb 02, 2012 10:07 am

Re: Boot time on original Pi

Tue Jul 02, 2019 3:44 pm

Hi,

For buildroot tutorial, I have a French one : https://www.blaess.fr/christophe/articl ... buildroot/
I think it is not too difficult to follow : first part is creating the toolchain () , second part is creating a basic system ("système complet"). "Installation et boot" is self explanatory : we check that everything is ok. You'll see that on this basic image, boot time is around 3.9s + udhcpc failing lease)

Next part is adding some customization ("Affinement de la configuration"). That's where it talks about overlay, users, etc.
Then a new round of customization ("Nouvelles améliorations")

"Nouvelle valeur" means "new value for options.

And for kernel optimization, from the same writer : https://www.blaess.fr/christophe/2013/1 ... -embarque/ There's a link to a pdf paper, which tells you which parameter to change to optimize (part 4, "Paramétrage du kernel", mainly delete or disable some options)

If you need some help on translations, PM me.

And finally a video from my project (It is a RpiZero and kernel was not optimized yet 5 months ago) on youtube : https://youtu.be/OWlWnJYuoMY

Hien.

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Boot time on original Pi

Tue Jul 02, 2019 9:33 pm

My French is very rusty, but I think I can follow that! (Goggle translate helps!) Thanks. Your project looks very impressive and professional.

I had a quick go with TinyCore and PiCorePlayer as suggested by fruitoftheloom earlier. TinyCore boots in around 11 seconds on the 1B. PiCorePlayer about 20 seconds (although these are very rough measurements - me counting 1 elephant, 2 elephant etc!).

I guess my biggest concern around buildroot (or even something like tinycore) is security. I rely on Debian or Ubuntu taking care of all that for me. I know absolutely nothing about setting up networks correctly and this thing will be plugged directly into the router. How do you stop the device becoming part of a botnet? And if it is easy why are seemingly so many shop bought devices vulnerable?

tqhien
Posts: 35
Joined: Thu Feb 02, 2012 10:07 am

Re: Boot time on original Pi

Wed Jul 03, 2019 9:27 am

About security, it is up to you to install (or not) some security packages, to make SD read only, or to setup an authentification server in your network.

Debian and Ubuntu do that for you. With Buildroot, you have to select them yourself (but you know then how everything is tied together, so better knowledge, for better control and better security...)

Return to “General discussion”