rusefi Posted June 8, 2020 Posted June 8, 2020 OrangePiZero, Armbian_20.05.1_Orangepizero_buster_current_5.4.43 in RPI they have an option "Boot without waiting for network connection" which to be honest I do not know does what under the hood. What can I use with armbian to get faster boot time? I do not use Ethernet at all, I use wifi but do not want to wait for it to start using my device. Here is my boot statistics: root@orangepizero:~# systemd-analyze Startup finished in 7.295s (kernel) + 29.971s (userspace) = 37.266s graphical.target reached after 29.810s in userspace root@orangepizero:~# systemd-analyze blame 8.967s networkd-dispatcher.service 7.813s loadcpufreq.service 7.677s NetworkManager.service 7.379s wpa_supplicant.service 7.360s NetworkManager-wait-online.service 7.265s rng-tools.service 7.236s systemd-logind.service 7.174s sysstat.service 7.154s rsyslog.service
Werner Posted June 8, 2020 Posted June 8, 2020 You could for example remove all the WiFi stuff and/or compile your own kernel with WiFi in general removed. A higher quality sd card (A2 class) can make a difference.
Heisath Posted June 8, 2020 Posted June 8, 2020 You could also disable the "NetworkManager-wait-online.service" service. This normally waits a few seconds until some network connection has been established. Use "systemctl disable NetworkManager-wait-online.service" to disable it.
rusefi Posted June 8, 2020 Author Posted June 8, 2020 I need wifi to work I just do not need wifi to be ready to boot. Thank you Heisath that "systemctl disable NetworkManager-wait-online.service" has made things better! But RPI is still starting a bit faster. If needed I can setup both systems with exactly same SD cards, those play a role but probably but software configuration does matter as well I assume. orange@orangepizero:~$ systemd-analyze Startup finished in 6.549s (kernel) + 16.664s (userspace) = 23.214s pi@raspberrypi:~ $ systemd-analyze Startup finished in 1.642s (kernel) + 7.302s (userspace) = 8.944s orange@orangepizero:~$ systemd-analyze Startup finished in 6.549s (kernel) + 16.664s (userspace) = 23.214s graphical.target reached after 16.444s in userspace orange@orangepizero:~$ systemd-analyze blame 4.758s armbian-zram-config.service 4.697s armbian-ramlog.service 2.786s dev-mmcblk0p1.device 2.589s networkd-dispatcher.service 1.447s networking.service 1.280s NetworkManager.service 1.141s loadcpufreq.service 1.070s systemd-udev-trigger.service 1.027s keyboard-setup.service pi@raspberrypi:~ $ systemd-analyze blame 4.637s apt-daily.service 3.335s apt-daily-upgrade.service 1.833s dev-mmcblk0p2.device 1.700s udisks2.service 1.684s raspi-config.service 826ms systemd-fsck@dev-disk-by\x2dpartuuid-738a4d67\x2d01.service 709ms keyboard-setup.service 648ms ssh.service 622ms systemd-timesyncd.service 578ms user@1000.service 563ms lightdm.service 520ms wpa_supplicant.service 505ms plymouth-read-write.service 485ms plymouth-quit-wait.service 482ms networking.service
Tido Posted June 8, 2020 Posted June 8, 2020 1 hour ago, rusefi said: But RPI is still starting a bit faster. No, it is not. Your comparison is not equal. But I am sure you had broken SDcards on your RPi, because of missing functions like: 4.758s armbian-zram-config.service 4.697s armbian-ramlog.service
rusefi Posted June 8, 2020 Author Posted June 8, 2020 Tide, you are mistaken in your assumption that I had broken SD cards in my RPI. I have not yet rebooted it 1000 times since I guess it's about startup logs tourtering the card. I also believe that this is pretty standard RPI with very mild changes. can you please explain your arguments a bit better? I have a feeling that I can learn a lot from you. what would be a better comparison methodology? I guess I should wire up grio LED to both boards and see at which point user startup script would turn them on.
Tido Posted June 8, 2020 Posted June 8, 2020 3 hours ago, rusefi said: I have a feeling that I can learn a lot from you. I am afraid not, but I can guide you to some interesting information about ZRAM & RAMlog ZRAM https://forum.armbian.com/topic/5565-zram-vs-swap/ RAMlog or Log2RAM @Igor, which technology is in use nowadays? https://github.com/azlux/log2ram I cannot find anything about RAMLOG. And last, but not least, if you want to have the fastest booting device: https://forum.armbian.com/topic/8315-daily-tech-related-news-diet/?do=findComment&comment=87296 or https://forum.armbian.com/topic/8315-daily-tech-related-news-diet/?do=findComment&comment=90239
Igor Posted June 8, 2020 Posted June 8, 2020 11 minutes ago, Tido said: which technology is in use nowadays? Both are the same, different implementation. Those are just two out of services that boots up. If one wants to make a direct comparison, he needs to run same (and version of) services for start. Raspbian and Armbain are different enough that this is not possible without some tweaking and also on a hw level there are diffs. And a kernel version is not the same ... But if one wants to get a better boot time, things can be improved ... usually on cost of some features. Some services boots faster (old classic networking VS network manager, timesync daemon,...), some might be useless? I don't know without deep analysis ... If you come up with something that is generally usable, integration can be done https://www.armbian.com/get-involved
Werner Posted June 9, 2020 Posted June 9, 2020 A RaspberryPi and any board that is supported by Armbian cannot be compared really. At RaspberryPi a lot of people working with just a few boards while at Armbian just a few people working literally on hundreds of boards which not even share the same sources. You see while at their place they have plenty of time to tweak every aspect Armbian simply cannot do that due to lack of ressources. 1
Heisath Posted June 9, 2020 Posted June 9, 2020 Anyway, next steps to save time are: - completely remove NetworkManager (you need to do your network config the classic way then). - remove armbian zram and ramlog (which can be done via apt remove or just disable the services) - make sure your device does not run a fsck on every boot - remove u-boot 'prompt timeout' (the time the bootloader waits for user input before booting the system, I guess thats 3s default on armbian) Btw. no guarantee that your system works perfectly after above steps - there's a reason for every service running. 1
Recommended Posts