If you compare this graph with the previous one in this post, there’s a few things you should notice:

• First, the overall boot is happening about 1 minute quicker, with a fully loaded chassis coming in around 2:35. This does mean the graphs are not directly comparable, because while the events covered are essentially the same, the total time shown is less. This graph is 1:36, vs 2:15 on the older one.
• The green and gray spikes are considerably spikier, basically more narrow. This means that the accesses are short and fast, exactly what we want. Notice that the graph is now 2 seconds between data points instead of three.
• A full 1:00 of the 1:36 shown is CPU bound. This is what we want — get our disk access out of the way so the CPU can go as fast as it can. More blue at the top of the graph is ideal.
• I do feel that further optimization of the disk subsystem is possible. I’m not seeing read/write data rates beyond 4MB/s, which is sad. I really wanted 8MB/s and beyond. I have more testing to do to see if it’s the 16700A or the SCSI2SD. The SD card is not the bottleneck, proved through testing.
• There is this 9-second delay near the beginning of the boot. I think that might be DHCP request/reply time. I could go static and eliminate that. Interesting that both the disk and CPU are just sitting there twiddling their thumbs.