In a previous post I mentioned I’d be using a Pi as my exclusive desktop for a week, mostly to validate that it actually worked (and that our guesstimate that 4Gb RAM models were a reasonable “base”), but partly just for the experience!
Here’s a blow-by-blow account of how it went (there’s a TL;DR at end if you just want to scroll there :)…
Monday
I’d spent a few hours of the prior week setting up the system as I needed for work so, come this morning, everything was pretty much as my desktop normally is. Just on a Pi.
The Pi in question was a model 4B with 4Gb of RAM. It was booting off an ancient 120Gb SSD I had lying around from an old PC (in that small black case on the floor) and the eagle-eyed will note that there’s absolutely no active cooling or so much as a heat-sink installed on it in this picture. This is deliberate: I was reasonably sure it was going to thermally throttle at some point in the day, but I wanted to see how often that happened and how bad it was in practice. In other words, trying to answer the question: is this usable on an otherwise “naked” Pi?
Other than that, it was plugged into all the stuff I usually have plumbed into my beefy (but aging, and now somewhat dead) Core i7.
First tweaks:
- Audio from rhythmbox was choppy. I’d encountered this before and the hints from the “Audio” section of my earlier notes on the Pi desktop soon sorted this out. I’ll see what we can do about fixing this in the final image but given where it is I don’t think we can layer another file on top of it to implement this just for the Pi. This will probably be something I just have to stick in the release notes.
- The wrong audio output device was always selected on boot (should be “Analog Output - Built-in Audio”, but it was always “Multichannel Output - Built-in Audio”). On a hunch, I tried disabling the “module-switch-on-connect” lines in that same file (/etc/pulse/default.pa) and the problem was solved, although later I discovered this did mean that audio devices plugged into USB weren’t automatically selected. However, in my case, that’s ideal as I didn’t want them selected. Again, this may wind up being a release note.
- No swap. Not an issue initially, but I figured I’d be needing it sooner or later so I set up a 1Gb swap file and some monitoring scripts to regularly report things like system load, swap used, SoC temperature, etc. then added them to my steadily growing tmux configuration. Will see what can be done about fixing this for the release.
The first real test of the day: a meeting in Google Meet! I didn’t have any camera plumbed in at this point as I hadn’t succeeded in getting the camera module working properly with it yet, but I plugged in my nice USB microphone (that’s the USB audio device I mentioned above, which I don’t want to use for output, just input), fired up Chromium (installed from the snap-store) and somewhat nervously connected…
My group were evidently feeling somewhat shy (!) and everyone had their camera feed off, so it was just audio for this first challenge. Still, there were 5 people in the call so this was a reasonable first test. My audio apparently worked perfectly, and I had no issues hearing anyone at my end. All pretty smooth so far!
The Pi had been idling at ~60°C but that temperature slowly began to climb during the call. Within about 10 minutes it was at the 78°C mark (the Pi 4 throttles at 80°C) and I was starting to get a bit nervous. It took quite a while to get actually hit 80°C (maybe another 5 minutes) and at that point there was an occasional drop-out from the audio when others were speaking but otherwise the thermal throttling worked remarkably smoothly and everything stayed connected and working! So far, so good.
After the call was over, I dove into some other work and wound up compiling a couple of packages, writing up some notes and answering a few e-mails. The compiling all went fine, no swapping, no throttling, but the e-mail… This proved to be the next big challenge. Within minutes of firing up a GMail tab, swap space was being eaten into. It really is quite the memory hog!
Next tweaks:
- I activated zswap (appended zswap.enabled=1 to /boot/firmware/cmdline.txt) to see if that alleviated the 50% of my 1Gb swap space that’d been eaten. It seemed to (hovered around 20-30% after loading everything back up after rebooting to check my config), but these things are difficult to measure. YMMV.
Now, the next big challenge of the day. Another Google Meet call, but this time one that usually had 10+ participants and was very likely to involve video streams. I opted to try this one in Firefox instead (just to see if it would work). Within a minute of connecting it was obvious the Pi was struggling; the SoC temperature hit 80°C (the throttle point) within the first minute, and the video streams were mostly frozen. That said, at all points audio from the call was playing smoothly. With a fair bit of patience (very slow UI!), I disabled the incoming video feeds so the Pi just had audio to deal with.
Then the next challenge: using a shared Google Doc in another tab with the call still going. I was highly dubious the Pi would manage this given it was already into thermal throttling and swapping but I opened the tab anyway. It wasn’t quick to load but to my amazement it worked! I could see others editing away and could make a few edits myself. It wasn’t smooth, it did have a fair bit of cursor lag, but at all points the audio of the call kept playing mostly smoothly (a few crackles here and there, but nothing to affect comprehension), and I could actually work semi-productively. Remember, this was on the smallest of the Pis supported, with no thermal management at all and no shutting down anything I was already running.
Impressions at the end of the day: it’s slightly uncanny. Several times during the day I had to remind myself that I wasn’t on Ammy (my old Core i7). To be clear: I’m not claiming they’re in any way comparable on performance because they’re not. It’s trivial to find something that shows a massive performance difference (like Google Meet calls, or using GMail), but for most of the time, playing some music in the background while I hacked away at something in vim under a terminal window there was effectively no difference.
Then I’d need to flash a fresh image onto an SD card to test something, and suddenly I’d find myself reaching down to stick the card in the flash-reader that used to be in one of Ammy’s 5.25” bays and realize: nope, I’m on the Pi, and I need to use that nice little card-reader-slash-usb-hub I’d stuck on the desk instead.
To my genuine surprise, there wasn’t one thing the Pi failed at all day. Bear in mind this was an uncooled, more or less “stock” 4Gb Pi. Sure, the Google Meet calls weren’t great, and the GMail UI was hilariously laggy in some places … but they worked! Nothing crashed, nothing hung, and I had a day about as productive as any normal day.
If there’s one major difference that I’m just noticing it’s that, as I write this at 8 o’clock in the evening, my fingers are cold.
This may not sound too surprising: my office is in an unheated loft extension, it’s mid-October, and I’m in the North of the UK, so it’s pretty chilly outside. But normally Ammy, with her mammoth heat-sink, myriad fans, and frankly silly graphics card, has done a pretty good job of keeping things toasty and warm up here. She’s usually more than capable of raising the temperature in this room up to 30°C (in summer, things get ridiculously hot up here!). But the Pi has nothing like that thermal output. I might have to get some gloves…
Tuesday
Played around a bit with the configuration today to test some extra interfaces:
- Unplugged my usual Microsoft Intellimouse and tried out a bluetooth-based mouse instead. After some considerable pain getting it paired (which may be because it was previously paired to another machine), it’s working happily.
- Paired the Pi with my mobile phone and tried out bluetooth-based tethering. Totally uneventful: just worked.
- Also fitted a Pimoroni fan-shim to see what difference that made. Thankfully since this image doesn’t have U-Boot there were no problems with the fan-shim interrupting it.
To configure the temperature limit on the fan-shim, I simply added the following line to /boot/firmware/config.txt:
dtoverlay=gpio-fan,gpiopin=18,temp=65000
The only thing that brought the Pi into throttling territory yesterday were the calls in Google Meet, so I was interested to see what difference that made today. For the first call of the day there were only a few people with cameras on, but that was enough to quickly push the Pi’s temperature up.
Sure enough, the fan-shim kept things nicely below 65°C throughout the call. However, while this meant the audio was perfect throughout, I still wound up having to switch off most of the incoming video streams to keep things operating smoothly (Google Meet has a nice option to show a single standard-def stream at a time which seemed to work well). On this call, I was still audio only.
Then it was back to some compiling and documentation work, no problems here and everything went smoothly.
Next call: at this point while I’d managed to get a camera module installed, there was a problem in that the cable isn’t that long and I didn’t think people would particularly enjoy a view from under my desk (ahem). So, instead I plugged in the USB web-cam that normally sits on my monitor. I knew this was likely to give the Pi a hard time as USB web-cams typically chuck out an MJPEG stream and it would be up to Chromium to convert that to VP8 (or VP9?) which it wouldn’t use the GPU for. Sure enough, within a few seconds of connecting it was obvious the Pi was struggling (apparently my audio was choppy and dropping out), so I disabled my video feed and carried on as normal.
Finally: needed to modify some bits in JIRA (which we use for organizing the team’s work). JIRA was … hilariously slow. Nearly a full minute to just load the web-page. That said, JIRA is hilariously, painfully, slow on just about anything I’ve used (including Ammy) so I shouldn’t be surprised there. It was useable with a good dose of patience, but I’m thankful it’s not something I spend all my time in (can’t see my boss using it with a Pi :).
Verdict for the day: bluetooth was fine; the fan-shim is probably worthwhile for heavy workloads; USB web-cams are not going to be happy on video calls - use a camera module if at all possible (though cable length may be an issue).
Wednesday
Switched up to a Pi4 8Gb today. I was satisfied with the 4Gb’s performance with a decent dose of swap-file but was now interested in whether the 8Gb would swap at all and whether the (hypothetical) lack of swap would lead to any serious performance difference.
I transferred the fan-shim to this Pi so I could compare just the difference in RAM rather than anything else. Everything else was just unplugged from the old Pi and plugged into the new Pi. This is one of the things I love about the Pi: transferring all your storage between them is trivial (whether SD card or USB hard-drive based, it’s a lot easier than messing around inside a PC tower!).
There was some small faff getting the EEPROM configured to handle USB boot, but I had an SD card already setup to deal with that so it didn’t take more than a minute or two, then we were off.
The day was frankly uneventful. The usual mix of meets, compiling, emailing, etc. Only one thing of note really: no swapping. With a judicious set of JIRA, Gmail, and other hogs open I did manage to push the Pi to ~70% RAM usage but never managed to get it to actually swap (beyond trivial levels).
However, I can’t claim I actually noticed any performance difference. It felt pretty much exactly the same as the 4Gb model - the only difference being that I could see the swap monitor sat resolutely at zero all day.
Verdict for the day: the 8Gb is certainly a technical improvement, and for some that extra memory may be crucial (especially if you’re heavily into containers). Personally, I could live happily with a 4Gb plus some swap. Incidentally, even on an 8Gb I’d still keep some swap (say, 1Gb) around. The myths surrounding things being faster without swap are generally just that: myths.
Thursday
Still on the Pi4 8Gb today. I did cheat on my Google Meet calls today, and used my little laptop instead, largely because I knew one of the calls was going to involve screen-sharing and at this point I was pretty confident I knew the Pi’s limits and that I couldn’t smoothly deal with that, and ~10 people on the call too (on Google Meet, if you opt for “Audio only” it really means that and doesn’t permit screen-sharing; unsurprising but slightly annoying today).
Come the evening I had to “cheat” on another meeting call but for different reasons. I was due to give a quick talk for the Python North West group, which was using Zoom and, about 30 minutes before I was due to connect, discovered there’s no Zoom client for ARM. I wouldn’t have minded going audio-only for this one - I didn’t have any slides, just a few notes for a quick 10 minute segment. Still, it was back to the laptop again.
Everything else was basically uneventful:
- Needed to do some printing for my kid (colour laser printer on the network); worked without a hitch as it usually did on Ammy
- Needed to scan some pages for my partner (USB connected scanner); also worked without a hitch
- Did some quick image tweaks in Gimp (for this post!) with my partner’s Wacom tablet. No problems there either (just plug’n’play), though I’m pretty sure the extra RAM of the 8Gb model helped
Slight hassle plugging and unplugging all these USB things, but necessary. The Pi’s power supply isn’t a 750W beast like Ammy’s and doesn’t like having all my USB gadgets plugged in at once. Further, given I’m also booting off a USB attached device it’d be ill-advised to try and starve that of power! Might be time to invest in a powered USB hub…
Verdict for the day: if only Chromium could use the GPU for video encode and decode here. We’ll have to see what can be done about that (this is easier said than done; I have some inkling of what the Pi Foundation have gone through to get GPU decode into their version of Chromium, and it’s non-trivial).
Also, more stuff needs compiling for ARM. After the lack-of-Zoom-client discovery I went checking around for a few things. There’s no Chrome for ARM (well, outside of Chromebooks, so it’s obviously possible), no Zoom (as noted already), and no Skype. Signal and Telegram are available, but there’s definitely some prodding to be done here…
Side note: it was amusing to note the number of sites that happily offered me an amd64 deb!
Friday
Still on the Pi4 8Gb. Cheated on the Google Meet calls again with the laptop because, well, I might as well at this point. Everything else still on the Pi4, and uneventful. Watched a few YouTube videos; slightly jerky startup for the first second, and then played entirely smoothly while I was still working in another window.
Looks like it’s happy dealing with 1 video stream (even with it just doing CPU decoding), but pushing it to do more than that (e.g. during conferencing) isn’t viable without hardware acceleration.
Wound up doing some work in the evening on the piwheels website. The Firefox and Chromium developer tools are certainly a bit sluggish, but still useable. Once used to the slower refresh rate, it didn’t slow me down.
TL;DR / Conclusion
It’s so close to being a fully viable desktop replacement. The thing holding it back for me is video acceleration on Google Meet calls. If we had that, I could effectively switch to using this for the vast majority of my work, firing up the big PC (when it’s fixed :) only for seriously heavy duty things like video editing, or PC gaming, which are pretty rare activities for me, and which it really wouldn’t be realistic to expect a Pi to accomplish.
For others? Very much depends on typical uses and software. If you need Skype or Zoom, for instance, you’ll be stuck using the web-based versions (which’ll have the same issues as I did with Google Meet) because there’s no ARM compiled native clients (yet). But if you don’t need video conferencing (okay, that’s probably a fairly major ask in the midst of a pandemic where everyone in front of a computer is probably home-working), it’s a capable replacement.
Don’t go expecting Ryzen-like performance because you’re not going to get it … obviously. But I’d hardly call it sluggish either. Running off a USB-attached SSD everything starts up quickly and runs pretty smoothly. I was also impressed that, even on the 4Gb model, despite it eating into swap a bit, nothing ever felt like it was overwhelming the system. Though you might want to invest in a powered USB-hub!
Finally, for all the talk of the Pi 4 “running hot”, I only ever needed the fan-shim for video conferencing. My other workloads failed to push it into thermal throttling (though a few got close). The board certainly gets toasty, but it’s nothing like the small fan heater that Ammy was. If only it could heat my fingers up a bit!
Final note: any issues we haven’t sorted out by release, with any known workarounds, should be mentioned in the Groovy Release Notes.