Optimizing BeePi boot time

[Faucon2001]

Hi,
I am continuing a discussion started in XaAES skinning topic, but which needs a different one as being out scope of the initial thread.
Initial topic : viewtopic.php?f=27&t=27241&start=50

In summary, Paul mentioned the slowness of BeePi boot, which I fully agree.

re: dev setup. However, I dont like what is happening with Jessie on Pi (boot times, kswap, bloat), and I want "real feel" ST out of Pi, which is why I started original AFROS-update project (there are lots people still not like CLI on ST) but want MiNT power and flexibility. I am almost there, I have updated (firmware + wifi) of Amibian sd-image, just need to compile new ARAnyM with new SCSI and NativeFeatures support. I can get Amibian boot with wifi in about 3 sec's, but atm any apt-get upgrade seriously screws up its performance.

Excellent !! I did not know about Amibian ; I am going to have a look at it. Clearly, the linux side of BeePi is not optimized, both in term of size and boot time, and that's something I have in my todo list too. I am very interested in your work, so keep us posted on that.

On my side, I had a look at Amibian and it's true that booting speed is amazing quick compared to BeePi ; so what's the secret?
Basically it has nothing to do with the polemic around systemd vs old sysV init or upstart, because both Amibian and BeePi use Debian Jessie starting with systemd. it's just that BeePi needs more services to be loaded, that it has a serious issue with Network configuration service that I need to figure out and that Amibian starts the emulator side much earlier in the boot process giving the feeling of a 3 sec boot when BeePi starts it at the end.

A systemd-analyze plot gave me a clearer view :
First let's look at BeePi boot :

Total boot time is 14 sec before starting the emulator, which is not so bad in absolute value, BUT, network service is delaying it by 6.2 sec and rc.local which then launches Aranym takes another 4 sec to set up the network bridge. rc.local can be easily reduced by 2 sec because I had left some wait instructions in the script bringing the total boot to 12 sec. But why Network services take so long to start? Also notice that Aranym will only start around 13.5 sec (11.5 sec in the best scenario)

Now let's have a look to Amibian boot :

Total boot time is 6.5 sec, and the emulator starts after 2 sec (00startnow service) : wow !!!
Also Network service takes less than a second to start !!!

So in order of priority :
1- I have to figure out why Network service in BeePi takes so long to start, with a potential time reduction of 5 sec.
2 - Start the bridge setup earlier in the boot process, rc.local starting way to late : potential time saving 2 sec but I don't know if uml-net depends on Network service completion.
3 - Start Aranym earlier in the boot process, after the bridge setup surely (could it be done as EasyAraMint needs network setup to work?)
4 - remove the splashscreen
5 - Optimize the installed services.

More testing in perspective ; thanks Paul to open my eyes on that.

Regarding the issue after apt-get update, I would tend to say that id it works, don't fix it
Anyway, systemd-analyze plot may give you a better answer.

[Faucon2001]

Total boot time now decreased to 6.2 sec
I still have some more optimization to do, but I getting closer.

[LaurentS]

Woaouhh, I'm impatient to see this
Keep on the good work

Laurent

[Faucon2001]

I realized that my previous message could be wrongly interpreted when I refer to total boot time, it's the time to boot linux to the shell, not to boot Aranym, same thing for Amibian. Total boot time from power on to EasyAraMint desktop is around 25 sec.
Anyway, this is the result and how to do the modifications :

Connect with ssh or quit Aranym with the "linux" option as described in the manual.
Once on linux shell :
-Change /home/pi/host_fs/.system/interfaces and interfaces.eth with

Code: Select all

allow-hotplug lo
        iface lo inet loopback

allow-hotplug wlan0
   iface wlan0 inet manual
      wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
   iface default inet dhcp

allow-hotplug eth0
        iface eth0 inet dhcp


-Edit /home/pi/host_fs/.system/rc.local and remove all the "sleep 1" instructions

-Add to /etc/sysctl.conf

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1

Modify /etc/init.d/raspi-config with

Code: Select all

case "$1" in
  start)
      printf " No. Switching to ondemand scaling governor"
      SYS_CPUFREQ_GOVERNOR=/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      if [ -e $SYS_CPUFREQ_GOVERNOR ]; then
        echo "ondemand" > $SYS_CPUFREQ_GOVERNOR
        echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
        echo 100000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
        echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
        echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
      fi
      log_end_msg 0
    ;;
  stop)
    ;;
  restart)
    ;;
  force-reload)
    ;;
  *)
    echo "Usage: $0 start" >&2
    exit 3
    ;;
esac


if you want your Pi to work at maximum performance you can also change /etc/init.d/raspi-config like that :

Code: Select all

case "$1" in
  start)
      SYS_CPUFREQ_GOVERNOR=/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      if [ -e $SYS_CPUFREQ_GOVERNOR ]; then
        echo "performance" > $SYS_CPUFREQ_GOVERNOR
      fi
      log_end_msg 0

    ;;
  stop)
    ;;
  restart)
    ;;
  force-reload)
    ;;
  *)
    echo "Usage: $0 start" >&2
    exit 3
    ;;
esac


Moving the bridge setup earlier in the boot process is not reducing the boot time, as the bottle neck now is uml-utilities.
But it's still a 50% reduction of linux boot time vs previous version.

Next step will be to see if I can launch startemu as a service more early than in rc.local
Also, if you want to speed up mint boot, you can edit in EasyAraMint /etc/rc.d/rc.net and comment the network drive setup and apache section.

Enjoy

[paulwratt]

Philippe, thank you so much for taking the time to look at Amibian, as well as providing a detailed analysis of what you found, and how to make the changes in BeePi, awesome dude, thanks

I have Amibian installed on a Pi 2, and that may be the reason why you may not see any difference after an "apt-get upgrade" (you have Pi 3 dont you?).

The boot speed after upgrade is the same(ish), however the mouse, graphics and sound are all "stuttery". This was a while ago, some time before my first XaAES post, and I have seen there is a new update of Raspbian Jessie (PIXEL), so maybe it would be different now, I am about to find out. At the time it was serious enough to dump the upgraded image, and do the WiFi & SDL from scratch again.

Right at this very moment I am in the process of upgrading SD-cards, and a project I found (XiniX of SF) means I finally have a use for half a dozen (or a dozen) different OS's. Turns out that 99% of Raspberry Pi OS's are Raspbian based anyway, which is nice for porting.

I am not 100% sure, but I think (according to their changlog) that Amibian is now AmiBerry. From v1 (based on Minibian) they moved to v2 (based on DietPi). DietPi is is Jessie based, but no longer limited to Pi's. They have there own management and configuration (scripts?), and a hand tweek startup process, which is what MiniBian had, and AmiBian improved on.

I had a look through the AmiBian boot process (at the time of the upgrade), without the use of the tool you used (thanks for that too btw), and found SystemD has a multi file, multi layered, service depends process. Really convoluted at first observations, this is without getting into the service scripts themseves, but they are plain text so quite open to "improvement".

I am not against SystemD per se, however there is an increasing amount of software that wont build without serious work, hence the need for alternatives like Devuan and BedRock Linux, which still allow SystemD, just not dependency on SystemD (and DBus). As far as Raspbian goes, it has been steadily getting slower and more bloated. I found it running a "mandb" update on random boots, as opposed to after package installation.

Anyway, another of the OS's I now have is piCore (TinyCoreLinux for Pi), which like SliTazPi, runs in RAM, can hotplug SD card, and along with VoidLinux, does not use SystemD.

I am just about to download and install your BeePi Beta9, and will be trying some of the things I used to do with the Afros LiveCD and the Afros-Update I was working on. I hope to resurrect that 1Tb drive sometime this year, I have the hardware to do it, just need time and an "office", thanks for your encouragement there too

Are you going to release a new update, especially an updated Aranym (with the new SCSI & NativeFeature), along with your speedups. Did you find out what was going on with the networking issue? I saw Vincent has compiled a new FVDI, and Johan posted some updates to the FVDI repo on SF (around about the time of your posts)

At the core of all of my Atari related linux "stuff" has been the need to have a full working cross-compile setup. This appears to be one of the things the AmiBerry is targeting too. I intend (in the short term) to see if I can "plug" Aranym into AmiBian/AmiBerry, as I believe there is a large group who cross-develop for bot AtariST and Amiga. Combined with Olivier's work with MyAES and the use of Hatari to get a 68000 build, I believe the time is right for some form of multi-m68k cross-compile "package" or "OS", starting with say AmiPiTari (off the top of my head)

I have used the EasyAraMiNT setup before, with MiNT 1.16, and the later downloads available on the net with 1.17 & 1.18, and they are great. However I did notice that there is a section of the AtariST/AranyM community that did not want "all the cruft" of a full system, which is probably why AFROS LiveCD still gets weekly downloads

Essentially I want to be able to build HighWire on linux with Vincents cross-tools, and with Henk's AHCC, from the same source, which was possible at one point (with FreeMiNT GCC), however I dont know if anyone tried recently. I asked Henk a couple of (maybe 7) years ago if he would give AHCC a whurl, but he was busy with the FireBee updates (and Family I think too).

Anyway, you might be able to see where I'm going, without the need to build the development environment by hand every time I need it (hence the unseen work I did on AFROS-Update)

Thanks a bunch, again, for your trials and tribulations

Cheers

Paul