dietpi@DietPi:~$ sudo systemd-analyze
Startup finished in 3.613s (kernel) + 47.706s (userspace) = 51.320s
graphical.target reached after 47.531s in userspace
dietpi@DietPi:~$ sudo systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @47.531s
└─multi-user.target @47.530s
└─dropbear.service @47.263s +266ms
└─dietpi-boot.service @13.075s +34.165s
└─network-pre.target @13.067s
└─dietpi-preboot.service @11.717s +1.336s
└─dietpi-ramlog.service @11.323s +373ms
└─basic.target @11.303s
└─sysinit.target @11.292s
└─systemd-update-utmp.service @11.020s +268ms
└─systemd-tmpfiles-setup.service @10.514s +489ms
└─local-fs.target @10.460s
└─boot.mount @10.356s +101ms
└─systemd-fsck@dev-disk-by\x2dpartuuid-0e2887fb\x2d01.service @9.127s +1.210s
└─dev-disk-by\x2dpartuuid-0e2887fb\x2d01.device @8.684s
I installed DietPi hoping to get a boot time that could beat the ~20seconds I was getting to on Raspbian Lite.
I’m running an internet radio that basically consists of an amp/speaker, lcd screen, and a few buttons, a rotary encoder, and a few leds. As I’m setting up the sound, etc. I’m noticing that the boot times are almost double what I was starting with on Raspbian.
dietpi-boot.service is clearly the primary culprit, my question is if it is normal at all for that service to take so long, and how might I stop it from taking so long?
if time-sync takes that much time, your system is not having a valid network connection at the beginning or the used NTP server is not responding in time. Disabling the time-sync isn’t a good idea as your system will now running incorrect system time, and this could lead to other issues.
I’m pretty sure what’s happening is that the time stamps for the services are shifted when the system time is synced to the NTP server.
If I run a reboot cycle only changing the NTP setting, it takes 34-36 seconds on a stopwatch to getting my radio.service started (I stop the watch when I see the lcd on my radio indicate that the program is running).
Setting CONFIG_NTP_MODE=1 increases the recorded time for dietpi-boot.service by a lot (30-45s), but has no apparent change in reality.
Do you have a static IP applied or DHCP? Generally I’d recommend a static IP on any server to skip the DHCP lease step.The second thing is the time sync, so you may try to use a different NTP server, at best your router itself, if it serves as NTP server as well (many do): dietpi-config > Network Option: Misc > NTP mirror > Gateway, or one in your country, like uk.pool.ntp.org in UK.
We really need to put the time sync into background. I have already an idea how, including the removal of dietpi-boot.service in favour of the now more meaningful network-online.target (since a few versions already). I’ll have that as a target for v7.6, which should reduce boot times significantly when DHCP and/or time sync takes a while.
The random seed btw doesn’t seem to be part of the critical chain, so while it takes some seconds, it doesn’t prevent boot to continue. In fact, a quite recent change in the RPi kernel enhanced the situation by making available another entropy source on early boot stage, before the entropy daemon kicks in: https://github.com/raspberrypi/firmware/issues/1595
haveged is not required, as RPi has a hardware random generator which is used by the installed rng-tools5 (rngd process).
Static IP set, and tried local NTP mirror as well as router. When I started thinking about the router, I’m guessing that’s really the primary culprit; it’s closing in on 10 years old and being shared by a ton of devices with really limited options for QoS settings.
Re: timesync in the background, FWIW, I’m playing with the radio in parallel on Raspbian Lite and DietPi. In Raspbian the time syncs/updates about 10s after I have an audio stream playing.
Novice here, but my sense is that on a Pi Zero with a single core, there’s time to be gained by killing/shortening processes that are running in parallel to the parts of the critical chain. Random-seed seems to run right along side dev-mmcblk0p2.device, I know when I killed keyboard-setup that there was ~1s reduction in the time for that even though keyboard-setup was also not critical chain. It could just be my novice eyes though as I’m focused too much on that big random-seed time in DietPi when I’m seeing ~350ms for it in Raspbian. All of that happens within the first 10s of user space, which all seems not to be captured by critical-chain.
Makes sense that a single-core device cannot benefit from parallelism too much, but considering that many boot tasks make use of quite different hardware resources, it will still benefit: The root mount depends on hardware initialisation of the SD card, probably udev, time sync on network initialisation and initial connection time, others may be limited by disk I/O speed and others may limit the CPU alone. Would be actually interesting to see a details CPU load, RAM, net and disk I/O evolution during boot, together with the currently running tasks. Only problem may be that the monitoring itself may consume significant CPU time on such a little SBC and hence messes with the true results . Not sure if there is some way that is more integrated into the kernel or at least into systemd .
. Not sure if there is some way that is more integrated into the kernel or at least into systemd