After the short lived success of the SSD last night, I’ve returned to figure out why the entire system would hang up in excess of 10 seconds, quite often. I suspected heat was the issue, with the SSD getting too hot outside of its metal case. I noted, however, that the chips on the board were not making contact with the metal case of the SSD(which I removed), leading me to believe that it was not being used as a heat sink. My next thought, after remembering what I read on the label of my Intel SSD is that it’s drawing too much power and causing power drop outs. The 120GB Intel SSD claims a power consumption of 0.7 amps. That is a fair bit of power from a Pi USB port. The 256GB SSD might draw even more. The Pi is currently being powered from the Pidock 400, which is plugged into a cheap old 12 volt power supply I had laying around. The power supply got very hot last night, and may be causing problems. Saving progress on the log, shutting down, testing again with the SSD. Currently booting off of the Samsung Bar 32GB drive.

I’ve gotten the system running off the SSD once again, using the Vilros power supply the Pidock came with. It seems to be a high quality supply, with a UL rating, and output of 12 volts at 3 amps. It seems to be working so far, but the lock ups were seemingly random, so we shall see. In order to know exactly when a lockup occurs, I am leaving the system monitor running off to the side so I can watch the CPU graph. So far it has been a few minutes of typing with the monitor running and Firefox sitting idle on the other side of the screen. If the issue is one of power supply, the problem should go away. If it’s an issue of heat, it should come back when the system heats up. I’ve turned off all overclocking since this problem occurred, and I can feel the difference in every day use.

After much tinkering, it would seem that I have sorted it out. I can no longer replicate the problem, which was important in testing this. I still do not trust it yet. I booted from my original drive and used the Gnome Disks application to check and repair the file system on the SSD, which it did find errors on. I would normally use the command line utility, but I am trying to use the tools that would be available to the average user, and non Linux users or general power users. This is important to me as I am trying to help the Pi 400 gain popularity with normal PC users. The dirty bit was set, indicating the drive was unmounted improperly. This tends to happen when you pull power from the system multiple times after a crash. Even after the repair, the problem persisted. I noticed a pattern, which is always critical in problem solving. I noticed that the system seemed to be working in the background, but all video output was frozen. As this drive was cloned from a known working drive, there shouldn’t have been any changes in software, but there was a hardware change that could have caused corruption when the data was cloned and the partition resized to fill the larger drive. After finally getting the temperature display software installed and working, I watched the temps of the CPU and SSD. Neither were getting hot enough to cause problems, as far as I could tell. It seemed to lock up when inputting from the keyboard into system utilities such as the terminal and the Pop Shop. Between this, the file system errors, and the previous problems with display lock up and video playback issues, I guessed it was possibly just a software problem at this point. Normally I would keep a system up to date, especially with the exciting new features that come out regularly for the Pi. I have been holding back updates on Pop!_OS since the beginning due to an unknown update breaking audio on the Pi 400 through HDMI. Deciding this new problem was far worse, and having a back up drive to work with, I decided to update the entire system. It froze up during the update, and I had to remove power once more. After using <sudo apt –configuure -a> to resume the upgrade process, I was able to finish it and reboot. The audio still works, which suggests that System76 have already addressed the issue. I now have an up to date system with working audio.

To really test the new found stability, I tried recreating the freezing issue. I opened the Pop Shop and started typing “temperature” which froze the system every time previously. It did not freeze this time, and I have been unable to cause further lock ups. I have converted the problem video file to a YouTube format with Handbrake, watching the temps, and have been writing this log up in LibreOffice Writer. The autosave feature saved my previous thoughts and recovered this document successfully. I am quite grateful for such features, despite the larger program that takes longer to open. Running from this SSD makes that far less of an issue though.
The next test is to try and play some video files, including the known problem file from previous tests. I’ll assume it will crash the system and save my log file before hand. I will open the system resource monitor first then try to play the file, with audio. The video playback test was a success for the new YouTube friendly file. It would appear that an update has gotten hardware acceleration working as the CPU usage averaged around 60% on all cores, instead of the usual 100% on all 4 cores. Trying the known problem file which uses the x264 codec and is known to max out the CPU and crash the system: The test was a partial success, with the video starting to play, then freezing on a single frame. CPU usage was about the same as with the new file, which is a marked improvement over previous tests. I was unable to actually watch the video, but it did not cripple or crash the system. I can work around this by either rendering from Kdenlive in a more reasonable format, or just immediately encoding with Handbrake after rendering to x264. I would prefer to render a video that can be reviewed immediately and uploaded if ready. Even if that is not an option, this process does work and would be reasonable for the occasional video production task. This entire system is not well suitable for full time production, but is viable for hobby use.

It appears that System76 have been busy upgrading Pop!_OS for the Raspberry Pi 4 and Pi 400, as the upgrades have improved performance and fixed crippling bugs. I will keep testing, and if I find no more bugs, I will clone this drive and continue testing. This OS is far too slow when run from something averaging less than 70MB/s, but is quite usable from an SSD averaging over 300MB/s. I still plan to upload the results from my tests, but wanted to get the SSD working first so I had a more usable system to work from. It is well worth the cost and effort to upgrade the boot drive from SD or flash drive to an SSD. One of the big advantages most people may not be aware of is that of drive heat. When a drive gets hot, it slows down. The Pi 4 and 400 dissipate enormous amounts of heat through the ports, including USB. The all metal Samsung Bar Plus flash drive, while excellent, gets too hot to handle while in use and runs unusually slow. One solution might be to use a USB 3.0 extension cable to get the drive away from the system, but the copper wires will still conduct heat. I may test this in the future. The bare SSD with the Sabrent adapter fits nicely into the Pidock 400 and sits over air vents in the bottom of the case. I am working on an idea to make an active cooling system for the Pi 400 that plugs into the ports on the back, adding a massive heat sink, and passing the ports through. Between port connectors, material cost for the heat sink(I’d go for solid copper) design time, and machining costs, this could be a very expensive undertaking. I feel such a thing is worthwhile, considering just how capable the Pi 400 is turning out to be. A massive heat sink with fans could really open it up to things like background video rendering, higher end games and emulation, or even industrial applications. The cooling is already reasonably good, but could be far better.

On the subject of cooling: The Pi 400, inside the Pidock 400, at stock speeds is sitting idle at 45C. I have seen it stay under 60C while rendering. I will do some thermal testing with overclocking and see how fast the Pi can run without throttling inside the Pidock. I am finding it incredibly difficult to find any info on the Pidock 400, so I might as well test it. Even at stock speeds, this Pi is fast enough for general use.

Check back later for test results. I will likely combine the thermal and drive speed tests into one log. I will also test drive speeds after they have had a chance to heat up during stress testing and see how performance changes. I need to figure out how to make nice looking graphs, so this is a perfect excuse. I’ve never actually needed to make graphs or presentations, come to think of it. Outside of school, that is. Time to learn a new skill.