MadMax Posted September 18, 2018 Posted September 18, 2018 I'm building a portable battery powered NAS because syncing and having everything multiple times on all my Android devices sucks. I took my old Banana Pi connected a SSD to the SATA port and made it a access point (no Samba yet installed). Booting from the 16GB SanDisk Ultra A1 is 27 seconds. Moving everything to the SSD in armbian config is also 27 seconds (no difference?) I know the Banana has not the fastest SATA and NIC and that USB 3 on the Rock64 is faster. But i don't copy tons of gigabyte to the device everyday and for streaming over the WiFi stick it's fast enough. I'm interested on the boot time of the Rock64 (eMMC or USB/SSD). If its not much faster then i see no reason to by a Rock64 for that. Also the Banana has the advantage that you can solder a battery to it.
tkaiser Posted September 18, 2018 Posted September 18, 2018 49 minutes ago, MadMax said: Also the Banana has the advantage that you can solder a battery to it Useless since BPi people 'forgot' to think also about powering a SATA disk when running on battery. You need an Olimex Lime or better Lime2 for this. Here is a table of our boards containing also 'armbianmonitor -u' output where you can see average boot times: https://github.com/armbian/testings/blob/master/table.md -- you need to provide 'armbianmonitor -u' output too of course if you want other opinions on why your booting takes too long.
MadMax Posted September 18, 2018 Author Posted September 18, 2018 Whats the difference using a LiPo on the BPi or Lime? Where can i see the boot time in that table? Mine takes to long? I don't know what is normal. I was using a stopwatch...
tkaiser Posted September 18, 2018 Posted September 18, 2018 6 minutes ago, MadMax said: Whats the difference using a LiPo on the BPi or Lime? https://olimex.wordpress.com/2016/01/07/a20-olinuxino-lime-server-with-320gb-hdd-works-on-lipo-battery-over-6-hours/#comment-21182 And I was talking about 'armbianmonitor -u' twice above...
MadMax Posted September 18, 2018 Author Posted September 18, 2018 On the BPi is no power on the SATA Power connector? So why not just using a 5V Step-Up regulator? I don't see how armbianmonitor is telling me the boot time.
Igor Posted September 18, 2018 Posted September 18, 2018 33 minutes ago, MadMax said: So why not just using a 5V Step-Up regulator? Lime has it build on the board, on Banana you have to make one. 33 minutes ago, MadMax said: I don't see how armbianmonitor is telling me the boot time. We do. Providing support is usually possible only if we see logs and "armbianmonitor -u" is a collection of them. If you keep them for yourself don't expect any help or hints. http://ix.io/1kQc 16s http://ix.io/1lhu 7s
MadMax Posted September 18, 2018 Author Posted September 18, 2018 It's cheaper to buy a 4€ Pololu Step-Up regulator than a 60€ Lime. You do but i want to see it also :-) Here is mine: http://ix.io/1mVc Question was more if eMMC is much faster than a A1 SD and not why mine is so slow. Because i did not think until now it is slow - is it? I have no comparison to eMMC and my RPi's and the Odroid O2 are not faster then the BPi...
Igor Posted September 18, 2018 Posted September 18, 2018 10 minutes ago, MadMax said: Question was more if eMMC is much faster than a A1 SD and not why mine is so slow. Since I don't have the exact data for eMMC that is found on Lime (check here if there are any tests https://forum.armbian.com/topic/954-sd-card-performance/) I can't tell. Generally speaking, eMMC is way faster in small files and little faster in sequential r/w operations. And it's more reliable than SD cards. 13 minutes ago, MadMax said: Because i did not think until now it is slow - is it? It's normal speed. You can compare your results to https://github.com/armbian/testings/blob/master/table.md. The fastest SD card used in those tests is A1 Samsung 32G.
MadMax Posted September 18, 2018 Author Posted September 18, 2018 I still don't know where i see the boot time in armbianmonitor. Where do you see that A1 Samsung? I was using a stopwatch from plugin until i saw the login and that was 27 seconds. I thought booting from the SSD makes a big difference because of I/O but there is no difference to the micro SD. Is the CPU or the SATA on the BPi a bottleneck when it comes to booting? Also just found out that "systemd-analyze blame" command: ~# systemd-analyze blame 9.024s networking.service 4.245s armbian-hardware-monitor.service 3.272s dev-sda1.device 3.151s systemd-rfkill.service 2.406s dev-zram1.device 2.268s dev-zram2.device 2.210s dnsmasq.service 1.692s systemd-udev-trigger.service 1.588s armbian-ramlog.service 1.577s hostapd.service 1.497s keyboard-setup.service 1.285s armbian-zram-config.service 1.224s loadcpufreq.service 1.016s ntp.service 883ms systemd-journald.service 845ms ssh.service 824ms systemd-logind.service 623ms rc-local.service 612ms rsyslog.service 605ms sysstat.service 582ms user@0.service 427ms systemd-fsck@dev-disk-by\x2duuid-e727db0f\x2dc49e\x2d438d\x2dbc29\x2deedf14228e88.service 370ms systemd-modules-load.service 328ms resolvconf.service 325ms systemd-user-sessions.service 312ms systemd-update-utmp.service 289ms kmod-static-nodes.service 280ms cpufrequtils.service 272ms fake-hwclock.service 271ms alsa-restore.service 258ms systemd-tmpfiles-setup.service 251ms sysfsutils.service 230ms systemd-udevd.service 227ms systemd-journal-flush.service 220ms sys-kernel-debug.mount 218ms systemd-tmpfiles-setup-dev.service 184ms systemd-sysctl.service 180ms systemd-remount-fs.service 178ms media-mmcboot.mount 162ms dev-mqueue.mount 144ms sys-kernel-config.mount 136ms systemd-random-seed.service 117ms console-setup.service 96ms armbian-hardware-optimize.service 72ms systemd-update-utmp-runlevel.service 66ms boot.mount 52ms tmp.mount
Igor Posted September 18, 2018 Posted September 18, 2018 4 minutes ago, MadMax said: I still don't know where i see the boot time in armbianmonitor. Type dmesg and you will see times in front of boot log entries. Not the most proper way but you see if something is wrong right away. 7 minutes ago, MadMax said: I was using a stopwatch from plugin until i saw the login and that was 27 seconds. This is better. There is a delay in u-boot as well, especially if you have some USB devices which are scanned, there is some boot delay by a purpose that you can break booting and get into u-boot prompt. 9 minutes ago, MadMax said: Is the CPU or the SATA on the BPi a bottleneck when it comes to booting? CPU. 5 minutes ago, MadMax said: Where do you see that A1 Samsung? You mean in the log? ### mmc0:59b4 info: cid: 1b534d303030303010915c060100fa93 csd: 400e00325b590000775d7f800a4000a3 scr: 0235800300000000 date: 10/2015 name: 00000 type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0x915c0601 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512
tkaiser Posted September 18, 2018 Posted September 18, 2018 51 minutes ago, MadMax said: Question was more if eMMC is much faster than a A1 SD and not why mine is so slow These are two different questions. The media makes no difference whatsoever if it's about booting times, even most crappy SD cards perform the same: https://forum.armbian.com/topic/4167-f2fs-revisited/?do=findComment&comment=30835 If you for whatever reasons need short boot times Armbian is not for you. We optimize constantly but never for short boot times but for better operation once the board has finished booting If you need short boot times you need to become an expert to learn how to eliminate the various bottlenecks (see https://forum.armbian.com/topic/1089-usbootpi/ for example) If you're interested in times relevant for your use case you need to measure the time until the respective service is usable (and not until a login prompt appears somewhere).
MadMax Posted September 18, 2018 Author Posted September 18, 2018 33 minutes ago, tkaiser said: The media makes no difference whatsoever if it's about booting times, even most crappy SD cards perform the same. That was the answer to my question in the first place. Funny that there is no difference. So no reason for me to buy another board and let the BPi spoil in the drawer.
tkaiser Posted September 18, 2018 Posted September 18, 2018 38 minutes ago, MadMax said: That was the answer to my question in the first place Well, don't think so. You asked another entirely different question: 5 hours ago, MadMax said: I'm interested on the boot time of the Rock64 (eMMC or USB/SSD). And... Rock64 will boot way faster than your outdated Banana Pi regardless of the boot media. But as already said: if you're interested in a specific use case IMO you should look also at this use case. Stop watch waiting for login prompt is pretty much irrelevant for 'wireless NAS being ready to serve' Check your own armbianmonitor -u output for 'link becomes ready' occurrences then you know how much time it already takes since the kernel has started for the wireless link to come up. I've seen quite some delays with some USB wireless dongles in the past so this is something at least I would take care of.
MadMax Posted September 18, 2018 Author Posted September 18, 2018 It's not that I'm fighting for seconds. It was more curiosity. If i can use this thing after ~30 seconds everything is OK. My TV or satellite receiver are slower :D I will buy a Rock64 next month for another use case (surveillance cam display h265) and then i will see how the boot time is there. And if there is no difference in boot time between SD and eMMC i now know i don't need a eMMC there.
chwe Posted September 18, 2018 Posted September 18, 2018 7 hours ago, tkaiser said: Lime2 for this. btw. the table you mentioned would be happy to see some reports for the Lime2
Igor Posted September 18, 2018 Posted September 18, 2018 55 minutes ago, chwe said: btw. the table you mentioned would be happy to see some reports for the Lime2 Mine is dead for an unknown reason.
tkaiser Posted September 18, 2018 Posted September 18, 2018 4 hours ago, chwe said: the table you mentioned would be happy to see some reports for the Lime2 My Limes are productive and of course I froze Armbian updates. The 'boards bricked by Armbian updates for no reason' shit show from earlier this year was an important lesson...
chwe Posted September 18, 2018 Posted September 18, 2018 well https://github.com/armbian/testings will hopefully be part of tool/work-flow to avoid frustration with updates.. so that the average user doesn't need freezing his system in productive use-cases.
Recommended Posts