Looking for a twist on the minimum boot time which is instead minimum boot power with the understanding that they are intimately related. Problem is to come up from cold start establish a WiFi connection and dump a small block of data < 1k to the cloud and cold shutdown and repeat every 12 hours. Don’t need it to do anything else = strip to bear minimum because it does not stay up for long. Thinking i can do without a bunch of stuff and could make this in 10 seconds (presuming some heroic tweaking) and if not what are more believable boot-time numbers?
well, most time you will spend on connecting to WiFi and to receive a DHCP address. Best would be to use a wired connection with Static IP. Just to get an idea how this could influence your boot time, an example from my RPi3B+ (Ethernet). You need to read from bottom to top.
DHCP IP (7.7 seconds)
root@DietPi3:~# 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 @7.746s └─multi-user.target @7.745s └─getty.target @7.744s └─email@example.com @7.743s └─systemd-user-sessions.service @7.715s +23ms └─network.target @7.707s └─firstname.lastname@example.org @2.898s +4.807s └─network-pre.target @2.894s └─dietpi-preboot.service @2.727s +165ms └─dietpi-ramlog.service @2.580s +143ms └─basic.target @2.570s └─sysinit.target @2.567s └─systemd-timesyncd.service @7.452s +194ms └─systemd-tmpfiles-setup.service @2.349s +43ms └─local-fs.target @2.340s └─boot.mount @2.277s +61ms └─systemd-fsck@dev-disk-by\x2dpartuuid-1cc4b388\x2d01.service @1.877s +394ms └─dev-disk-by\x2dpartuuid-1cc4b388\x2d01.device @1.864s root@DietPi3:~#
STATIC IP (3 seconds)
root@DietPi3:~# 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 @3.071s └─multi-user.target @3.070s └─getty.target @3.069s └─email@example.com @3.068s └─systemd-user-sessions.service @3.041s +22ms └─network.target @3.033s └─networking.service @2.865s +166ms └─network-pre.target @2.858s └─dietpi-preboot.service @2.685s +171ms └─dietpi-ramlog.service @2.539s +141ms └─basic.target @2.529s └─sysinit.target @2.527s └─systemd-timesyncd.service @2.366s +159ms └─systemd-tmpfiles-setup.service @2.305s +44ms └─local-fs.target @2.297s └─boot.mount @2.267s +28ms └─systemd-fsck@dev-disk-by\x2dpartuuid-1cc4b388\x2d01.service @1.864s +399ms └─dev-disk-by\x2dpartuuid-1cc4b388\x2d01.device @1.830s root@DietPi3:~#
network-pre.target is reached in both case at around 2.9 seconds. Establashing a network connect on STATIC IP is done in less than 200ms, while it takes nearly 5 seconds on DHCP
Other than that, DietPi is already stiped down to a minimum. However, you could disable some process we run at boot, if not needed. Like time sync or apt package checks. This might not reduce boot times but will save system resources needed during boot process.
Googling RPi zero deep sleep shows no go…there is a hat with a RTC that can schedule boots and whatnot
Witty Pi Mini: RTC + Power Management for Raspberry Pi | UUGear
How to Build Root on Raspberry Pi - Boots in 5 seconds!!! - YouTube
Tiny Core Raspberry Pi Zero W Install - YouTube
This too Himesh’s Blog: Fast boot with Raspberry Pi (himeshp.blogspot.com)
Would something like a ESP32 or Raspberry Pi Pico be able to do something like that?
How to Send and Receive Data Using Raspberry Pi Pico W and MQTT (Updated) | Tom’s Hardware (tomshardware.com)
Might take a gander at TinyCore (PiCore) as well
piCore (Tiny Core) Linux on Raspberry Pi - IoTbyHVM - Bits & Bytes of IoT