Calculate systemd unit startup order and dependency chain resolution time.
systemd starts units in parallel wherever dependency ordering (After=/Before=/Requires=/Wants=) allows, so total boot time isn't the sum of every unit's start time — it's the length of the longest dependency chain (the critical path), the same concept `systemd-analyze critical-path` reports directly from real boot data. Units with no dependency relationship to a slow chain start concurrently and don't add to total time unless one of them individually takes longer than the chain itself; this calculator models a simple sequential chain (units that must start one after another) alongside independent parallel units, and reports whichever path is actually the bottleneck.
Critical path
critical_path = max(sum(sequential_chain_times), max(parallel_unit_times))
`systemd-analyze critical-path` prints the actual chain of units that determined total boot time, and `systemd-analyze blame` lists every unit sorted by how long it individually took to initialize — the former shows what limited boot time, the latter shows what was simply slow (which may or may not have been on the critical path).
If that slow unit runs in parallel alongside an even slower dependency chain, it's not actually the bottleneck — speeding it up won't reduce total boot time until the chain it's racing against is also addressed. This is exactly why `systemd-analyze blame`'s 'slowest unit' list and `critical-path`'s actual bottleneck chain can point to different units.
`systemd-analyze plot > boot.svg` generates a full Gantt-chart-style SVG showing every unit's start/finish time and overlap, which is the most complete way to see parallelism and identify unexpected serialization between units that shouldn't need to block each other.