Raspberry Pi4's and v. 8.4.9?
Moderators: Site Moderators, FAHC Science Team
Raspberry Pi4's and v. 8.4.9?
Hi, I've had running 4 Pi4's running Folding@Home 24/7 for several years on the medium setting (two CPU's). Three of these Pi's also run some BOINC projects.
The client version has been 7.6.21, but now I noticed there is a newer version 8.4.9. However this is announced as for Raspberry Pi5.
My Pi4B's each have their own PoE 'HAT' with their own quality fan (Austrian N??? brand with a home built controller) and are built into a 'tower'. So quite a bit of effort (and money) has gone into this, but now I am wondering how to go forward with this?
Can I expect to keep them running on 7.6.21 for a foreseeable time?
Two have 8 MB of RAM, the other two 4 MB. The OS is Buster 64b.
Do I need to start anew with Pi5's just to use 8.4.9? (I doubt I'll start anew)
Will my Pi4's run out of WU's at some point if they stay on 7.6.21?
At the moment two of them have no WU from F@H, which is quite strange. I haven't seen that before. Those Pi's keep trying to download work units, but no success. The two that do have work, have ETA's of a few days. They have been like that for a few weeks, so I guess they are getting new WU's where the other two don't. All four have the same setup OS and software wise. The ones that don't have work also miss work and/or collection server IP's (0.0.0.0).
(I assume there will be voices to say there's little point in running F@H on Pi's, but this is what I have working in the corner of my cottage ... I ran F@H for a while on my Intel NUC and even mounted to the wall, but it is my workstation now and I carry it between home and cottage in different countries. If I run F@H on it, I know the fan will start to run at full speed on my desk and that's too much ...)
Thanks for shedding your light!
The client version has been 7.6.21, but now I noticed there is a newer version 8.4.9. However this is announced as for Raspberry Pi5.
My Pi4B's each have their own PoE 'HAT' with their own quality fan (Austrian N??? brand with a home built controller) and are built into a 'tower'. So quite a bit of effort (and money) has gone into this, but now I am wondering how to go forward with this?
Can I expect to keep them running on 7.6.21 for a foreseeable time?
Two have 8 MB of RAM, the other two 4 MB. The OS is Buster 64b.
Do I need to start anew with Pi5's just to use 8.4.9? (I doubt I'll start anew)
Will my Pi4's run out of WU's at some point if they stay on 7.6.21?
At the moment two of them have no WU from F@H, which is quite strange. I haven't seen that before. Those Pi's keep trying to download work units, but no success. The two that do have work, have ETA's of a few days. They have been like that for a few weeks, so I guess they are getting new WU's where the other two don't. All four have the same setup OS and software wise. The ones that don't have work also miss work and/or collection server IP's (0.0.0.0).
(I assume there will be voices to say there's little point in running F@H on Pi's, but this is what I have working in the corner of my cottage ... I ran F@H for a while on my Intel NUC and even mounted to the wall, but it is my workstation now and I carry it between home and cottage in different countries. If I run F@H on it, I know the fan will start to run at full speed on my desk and that's too much ...)
Thanks for shedding your light!
-
- Site Admin
- Posts: 8087
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Studio M1 Max 32 GB smp6
Mac Hack i7-7700K 48 GB smp4 - Location: W. MA
Re: Raspberry Pi4's and v. 8.4.9?
Some of the CPU projects have been limited to 3 or more CPU threads due to an assignment problem with v8 clients. That may be why you are seeing no WUs at times.
In theory if you are getting work on the Pi 4s using 7.6.21 you should continue to get it with 8.4.9. I believe the minimum listed on the download page is due to that being the machine they can benchmark for during testing of new projects. But projects small enough for the Pi 4s may get scarcer as time goes on. It is not required to update to v8 at this point. v7.6.21 is still supported, and will not be the reason your Pi 4s run out of WUs.
In theory if you are getting work on the Pi 4s using 7.6.21 you should continue to get it with 8.4.9. I believe the minimum listed on the download page is due to that being the machine they can benchmark for during testing of new projects. But projects small enough for the Pi 4s may get scarcer as time goes on. It is not required to update to v8 at this point. v7.6.21 is still supported, and will not be the reason your Pi 4s run out of WUs.
-
- Posts: 1532
- Joined: Sun Dec 16, 2007 6:22 pm
- Hardware configuration: 9950x, 7950x3D, 5950x, 5800x3D
7900xtx, RX9070, Radeon 7, 5700xt, 6900xt, RX 550 640SP - Location: London
- Contact:
Re: Raspberry Pi4's and v. 8.4.9?
rPI 4 at CPU:4 has issues completing WUs in time consistently, let alone CPU:2. So we rarely enable any projects for that kind of hardware.
I would urge people not to invest in such low powered devices just to run FAH on them.
I would urge people not to invest in such low powered devices just to run FAH on them.
Re: Raspberry Pi4's and v. 8.4.9?
Like muzikaz says, there's not much reason to invest in them. But let me put into perspective just how much better you can do.
The Pi4 has four ARM Cortex-A72 cores. That's only 13.5 GFLOPS (the GPU is 32 GFLOPS but it is unused). That's not very much. And it consumes 12 watts to do that (2.7 GFLOPS/W). If you have the devices lying around and you aren't paying for electricity then there's no reason not to use them as long as they finish before the timeout. But there's no reason to invest in them.
It isn't that Raspberry Pi4's processor is bad. It is that it is optimized for best efficiency at low utilization. It is meant to sip watts when it's idle or nearly idle, but still has some margin for brief bursts of higher performance (at a severe efficiency cost). It's the opposite with something like a high-end AMD EPYC server processor. That thing is meant to run at max speed 24/7 without consuming more power than necessary, but will idle at like 100W!
If you want total silence, you could get a passively-cooled 15W x86 SBC and a passively-cooled 70W RTX 3050. That's 6700 GFLOPS for only 85W (79 GFLOPS/W). It's the equivalent of 500 individual Pi4 boards, but uses only 0.085kW instead of 6kW.
Investing in Pis for folding is like investing in a 48U rack full of top-end dual-socket EPYC servers to drive a digital picture frame.
The Pi4 has four ARM Cortex-A72 cores. That's only 13.5 GFLOPS (the GPU is 32 GFLOPS but it is unused). That's not very much. And it consumes 12 watts to do that (2.7 GFLOPS/W). If you have the devices lying around and you aren't paying for electricity then there's no reason not to use them as long as they finish before the timeout. But there's no reason to invest in them.
It isn't that Raspberry Pi4's processor is bad. It is that it is optimized for best efficiency at low utilization. It is meant to sip watts when it's idle or nearly idle, but still has some margin for brief bursts of higher performance (at a severe efficiency cost). It's the opposite with something like a high-end AMD EPYC server processor. That thing is meant to run at max speed 24/7 without consuming more power than necessary, but will idle at like 100W!
If you want total silence, you could get a passively-cooled 15W x86 SBC and a passively-cooled 70W RTX 3050. That's 6700 GFLOPS for only 85W (79 GFLOPS/W). It's the equivalent of 500 individual Pi4 boards, but uses only 0.085kW instead of 6kW.

Investing in Pis for folding is like investing in a 48U rack full of top-end dual-socket EPYC servers to drive a digital picture frame.
Re: Raspberry Pi4's and v. 8.4.9?
Thanks for the replies. I will study them again, when something comes up with the Pi's in my tower.
I built the tower with four Pi4B's and the PoE HATs many years ago. Maybe it was even before the corona virus pandemia. Buster 64 bits was available
When the laptop I was travelling with between home and cottage developed a keyboard failure, I got an Intel NUC and since it came with a wall mount and by the time had learned how investing in Raspberry Pi4 hardware for distributed scientific computing isn't really economically smart, I tried distributed computing on that NUC on the wall in a storage room for a while. I even went as far as acquiring a bulky passive cooling enclosure for it. However I needed the NUC as a desktop, so that experiment ended.
I found out the same NUC is not easy to get anymore and the passive cooling enclosure doesn't fit other NUC's ...
So, one day when I live to decide I need a new NUC, I can put the current one to good use for F@H and Boinc with passive cooling, if science hasn't been killed by we all know who.
The thing is that in a cottage you need to keep a decent minimum temperature also when you're not there to keep mould from invading.
Some heating is needed all the time and especially in winter. So I don't mind the 'heat' from those Pi's. The thermostat takes care of the overal situation.
Indirectly inspired by the replies here I even went so far as to overclock one Pi today as a test. It runs OK at 2000 MHz. F@H Estimated TPF (time per fold, I suppose) is the lowest of all four Pi's, but then TPF varies a lot anyway.
Despite those computations being scientific, this Pi-stuff is a hobby for me. I have 10 of them running all the time in some capacity, NAS offsite backup, ADS-B, two camera's, three environmental sensors, a hub for connecting through a CGNAT from the outside ...
All on Linux in some shape or form.
I built the tower with four Pi4B's and the PoE HATs many years ago. Maybe it was even before the corona virus pandemia. Buster 64 bits was available
When the laptop I was travelling with between home and cottage developed a keyboard failure, I got an Intel NUC and since it came with a wall mount and by the time had learned how investing in Raspberry Pi4 hardware for distributed scientific computing isn't really economically smart, I tried distributed computing on that NUC on the wall in a storage room for a while. I even went as far as acquiring a bulky passive cooling enclosure for it. However I needed the NUC as a desktop, so that experiment ended.
I found out the same NUC is not easy to get anymore and the passive cooling enclosure doesn't fit other NUC's ...
So, one day when I live to decide I need a new NUC, I can put the current one to good use for F@H and Boinc with passive cooling, if science hasn't been killed by we all know who.
The thing is that in a cottage you need to keep a decent minimum temperature also when you're not there to keep mould from invading.
Some heating is needed all the time and especially in winter. So I don't mind the 'heat' from those Pi's. The thermostat takes care of the overal situation.
Indirectly inspired by the replies here I even went so far as to overclock one Pi today as a test. It runs OK at 2000 MHz. F@H Estimated TPF (time per fold, I suppose) is the lowest of all four Pi's, but then TPF varies a lot anyway.
Despite those computations being scientific, this Pi-stuff is a hobby for me. I have 10 of them running all the time in some capacity, NAS offsite backup, ADS-B, two camera's, three environmental sensors, a hub for connecting through a CGNAT from the outside ...
All on Linux in some shape or form.
Re: Raspberry Pi4's and v. 8.4.9?
I suppose if they're being used as heat, it's still infinitely more FLOPS than the resistive coil in a space heater!
But be sure they are able to return WUs before the timeout ends, not only before the deadline ends. If the timeout expires, then even though you get the base points, the work is "wasted" because it was already sent out to someone else and your returned WU won't be used for science.
But be sure they are able to return WUs before the timeout ends, not only before the deadline ends. If the timeout expires, then even though you get the base points, the work is "wasted" because it was already sent out to someone else and your returned WU won't be used for science.
-
- Posts: 1532
- Joined: Sun Dec 16, 2007 6:22 pm
- Hardware configuration: 9950x, 7950x3D, 5950x, 5800x3D
7900xtx, RX9070, Radeon 7, 5700xt, 6900xt, RX 550 640SP - Location: London
- Contact:
Re: Raspberry Pi4's and v. 8.4.9?
TPF is Time Per Frame, Time Per Frame is time it takes to progress 1%
Re: Raspberry Pi4's and v. 8.4.9?
As odd as it may seem, the latter is a very helpful comment. I've not been paying too much attention to details like that, assuming I would get some kind of warning, if I'm late ...arisu wrote: ↑Mon Apr 14, 2025 10:38 am I suppose if they're being used as heat, it's still infinitely more FLOPS than the resistive coil in a space heater!
But be sure they are able to return WUs before the timeout ends, not only before the deadline ends. If the timeout expires, then even though you get the base points, the work is "wasted" because it was already sent out to someone else and your returned WU won't be used for science.
Re: Raspberry Pi4's and v. 8.4.9?
Since the overclocking was successful on the bottom Pi, I did the same to the other 3 and paused all concurrent BOINC tasks on them to get the F@H tasks to run quicker and hopefully be ready in time before the 'timeout' moment.
After a reboot, F@H would not take all 4 cores the two machines that had been running concurrent BOINC tasks before. Judging by CPU percentages only about 2 CPU's on the one machine and about 3 on the other one. HTOP shows only 2 resp. 3 /var/lib/fahclient/cores ... processes running. There's no throttling taking place. The CPU temperatures stay low enough as all four have heatsinks and their own fan (running at max. 95%).
Is it perhaps so that some WU's (that have been running) cannot make use of more than a set number of cores?
Will waiting for these tasks to end - allbeit late - cause new WU's to load that can make use of all 4 CPU's, like on the other two machines?
All 4 Pi's have cpu:4 in the description of Folding slots ...
After a reboot, F@H would not take all 4 cores the two machines that had been running concurrent BOINC tasks before. Judging by CPU percentages only about 2 CPU's on the one machine and about 3 on the other one. HTOP shows only 2 resp. 3 /var/lib/fahclient/cores ... processes running. There's no throttling taking place. The CPU temperatures stay low enough as all four have heatsinks and their own fan (running at max. 95%).
Is it perhaps so that some WU's (that have been running) cannot make use of more than a set number of cores?
Will waiting for these tasks to end - allbeit late - cause new WU's to load that can make use of all 4 CPU's, like on the other two machines?
All 4 Pi's have cpu:4 in the description of Folding slots ...
-
- Site Admin
- Posts: 8087
- Joined: Tue Apr 21, 2009 4:41 pm
- Hardware configuration: Mac Studio M1 Max 32 GB smp6
Mac Hack i7-7700K 48 GB smp4 - Location: W. MA
Re: Raspberry Pi4's and v. 8.4.9?
WUs assigned while the CPU thread setting is at a lower number will not us more threads. The next WU assigned and downloaded will use as many threads as there are set.
-
- Posts: 1532
- Joined: Sun Dec 16, 2007 6:22 pm
- Hardware configuration: 9950x, 7950x3D, 5950x, 5800x3D
7900xtx, RX9070, Radeon 7, 5700xt, 6900xt, RX 550 640SP - Location: London
- Contact:
Re: Raspberry Pi4's and v. 8.4.9?
No, FAH uses all what you can give. You need to set the slider accordingly.
And what Joe said
And what Joe said
Re: Raspberry Pi4's and v. 8.4.9?
The client will tell you (not loudly) if you have passed the timeout, but you should be folding on hardware that never lets the timeout pass. Even if it can finish well before the deadline. From a technical stand-point having a WU dump right away when the timeout expires (and not having a deadline at all) would be preferable. But the idea behind having a deadline too is that it encourages people to fold more and hopefully upgrade: viewtopic.php?t=42745ArjenR49 wrote: ↑Mon Apr 14, 2025 3:04 pmAs odd as it may seem, the latter is a very helpful comment. I've not been paying too much attention to details like that, assuming I would get some kind of warning, if I'm late ...arisu wrote: ↑Mon Apr 14, 2025 10:38 am I suppose if they're being used as heat, it's still infinitely more FLOPS than the resistive coil in a space heater!
But be sure they are able to return WUs before the timeout ends, not only before the deadline ends. If the timeout expires, then even though you get the base points, the work is "wasted" because it was already sent out to someone else and your returned WU won't be used for science.
In theory if your hardware always misses the timeout, it's almost the same as if you download WUs to maliciously let them expire. But the real benefit for allowing useless hardware is that people folding on useless hardware might one day start folding on better hardware. If someone folds for a year on a Pi that never meets the timeout and only meets the deadline is encourage to add even one GTX 1060 to their folding hardware, they will very quickly more than make up for any "damage" caused.
Re: Raspberry Pi4's and v. 8.4.9?
I never figured out what happens at the 'timeout' and what at the 'deadline'. For me a deadline is when the task should be ready.
I'm not a sportsman, but a timeout would be a break, although that's not logical at all. Why a timeout in computing?
One of the Pi's developed problems with the overclocking and started crashing, so I restored the original settings. However, for a while it ran quite odd tasks. Estimated TPF just seconds. Maybe F@H was trying to fathom what kind of computer it was running on? It still keeps crashing and getting low Estim. TPF times again, 16.5 sec. Maybe the Pi is broken. It didn't overheat (temp. readout on the taskbar) or throttle. This is getting hairy.
Or the SSD is corrupted ... I have a backup ...
All these 4 Pi's have the hardware watchdog enabled AFAIK, but as they can do RealVNC while running F@H, why would a watchdog think it has crashed?
The second Pi was chugging away on a task that was obviously going to be late for the timeout and possibly also for the deadline. So this morning I expected an alarm or error message, but nothing. The only strange thing I noticed was that the completed task stayed in the list for quite a while. A second task had been added and its state was 'ready'. Ready to go, apparently.
It feels a bit like an organism doing its thing without too much explaining.
I'm not a sportsman, but a timeout would be a break, although that's not logical at all. Why a timeout in computing?
One of the Pi's developed problems with the overclocking and started crashing, so I restored the original settings. However, for a while it ran quite odd tasks. Estimated TPF just seconds. Maybe F@H was trying to fathom what kind of computer it was running on? It still keeps crashing and getting low Estim. TPF times again, 16.5 sec. Maybe the Pi is broken. It didn't overheat (temp. readout on the taskbar) or throttle. This is getting hairy.
Or the SSD is corrupted ... I have a backup ...
All these 4 Pi's have the hardware watchdog enabled AFAIK, but as they can do RealVNC while running F@H, why would a watchdog think it has crashed?
The second Pi was chugging away on a task that was obviously going to be late for the timeout and possibly also for the deadline. So this morning I expected an alarm or error message, but nothing. The only strange thing I noticed was that the completed task stayed in the list for quite a while. A second task had been added and its state was 'ready'. Ready to go, apparently.
It feels a bit like an organism doing its thing without too much explaining.
Re: Raspberry Pi4's and v. 8.4.9?
If you recover from a crash, sometimes the v8 client will give you nonsensical performance estimates. I've had a CPU that only gets 200-400k PPD show me that it's getting nearly a billion PPD after a crash and estimated completion of the 12 hour WU in mere minutes. I think it happens because it thinks the WU is just being started and then suddenly sees a jump from 0% completion to whatever it crashed at and it thinks your CPU is made of magic and estimates TPF accordingly. It's only the estimate that is off. The cores are operating normally and you will get proper estimates on the next WU.
A deadline is when nothing is allowed after it. You can't turn in your homework after a deadline, even one second after. A timeout in computing just means the expiration of some asynchronously running timer. It can have a lot of meanings (usually something like "this task which could run for an undetermined amount of time has run too long so let's assume it's stuck and terminate it") but for FAH it is basically the preferred delivery date. If you turn it in before the timeout expires, you get bonus points if you also have a passkey set. If you turn it in after the timeout expires but before the end of the deadline, you get only the base points. But as I pointed out before you really should never let the timeout expire because that's just wasted work and the only reason you even get the base points is to try to keep you from leaving the project so that hopefully in the future you will upgrade your hardware.
So the second Pi tried to download a second WU while the first is still running? Are you playing with resource groups maybe? If it was 100% certainly going to be very late for the timeout, then dumping the WU is probably best for the project because the server is going to give it out to someone else to complete it, and dumping a WU causes it to be sent out to someone else immediately instead of stringing the collection server along and giving it a false hope that you'll finish the WU before the timeout expires. But be aware that the ETAs are sometimes wrong and you don't want to be hasty and dump a WU that isn't actually as slow as it seems. Dumping WUs should only be done in exceptional circumstances, and not being able to finish in time is one of those circumstances.

A deadline is when nothing is allowed after it. You can't turn in your homework after a deadline, even one second after. A timeout in computing just means the expiration of some asynchronously running timer. It can have a lot of meanings (usually something like "this task which could run for an undetermined amount of time has run too long so let's assume it's stuck and terminate it") but for FAH it is basically the preferred delivery date. If you turn it in before the timeout expires, you get bonus points if you also have a passkey set. If you turn it in after the timeout expires but before the end of the deadline, you get only the base points. But as I pointed out before you really should never let the timeout expire because that's just wasted work and the only reason you even get the base points is to try to keep you from leaving the project so that hopefully in the future you will upgrade your hardware.
So the second Pi tried to download a second WU while the first is still running? Are you playing with resource groups maybe? If it was 100% certainly going to be very late for the timeout, then dumping the WU is probably best for the project because the server is going to give it out to someone else to complete it, and dumping a WU causes it to be sent out to someone else immediately instead of stringing the collection server along and giving it a false hope that you'll finish the WU before the timeout expires. But be aware that the ETAs are sometimes wrong and you don't want to be hasty and dump a WU that isn't actually as slow as it seems. Dumping WUs should only be done in exceptional circumstances, and not being able to finish in time is one of those circumstances.
We need a Folding@home@home which uses distributed computing to simulate the behavior of the v8 client. It really does feel that way sometimes.

Re: Raspberry Pi4's and v. 8.4.9?
Thanks @arisu, more and more perspective.
I'm still on 7.6.21. Initially I wanted to know if I should upgrade my Pi's now or later and things like that.
Not really because of the heat generated by the Pi's is OK for me, at least in winter, but I did never paid attention to points received. I just keep the Pi's running their distributed computing tasks on their own VLAN and arranged for network access to them from the main LAN and from outside ('administrator' desktop and another Pi acting as an entry point to this LAN sitting behind a CGNAT). It's a hobby and I always hoped the DSC results are useful.
I've read about teams and resource groups, but no, my 4 Pi's just have been arranged in an cheap open tower construction (just pillars and perspex sheet) with 4 SSD's attached. It's good for cooling, but not so great for radio reception in this corner. No FM, no DAB+.
I knew from the start that arranging in a cluster is too demanding. They are all on their own. Originally three copies of the first one and kept 'in sync'.
I thought I don't have passkeys, but actually I do. Because of the impersonating thing. Not because of points. I never saw DSC as a competition.
I once tried Docker and stuff on a totally different Pi, or was it another of the same ilk, Home Assistant (?), but in the end I had to wipe it all out. Couldn't properly uninstall that fancy stuff, MQTT etc. etc. It was awfully complicated anyways. Always something left somewhere and 'phoning home'. It takes over the OS, more or less.
Overclocking (from 1500 MHz to 2000 MHz ondemand with over_voltage=6) initially seemed to work, but after one day it turned out to be unstable with F@H somehow. I have reverted all 4 Pi's.
An hour ago I started looking for a way to cancel a WU, and it seemed like there isn't/wasn't.
If you can tell me how to 'dump a WU' - may come in handy when fiddling with Pi settings and rebooting frequently - I'd like to know.
I use FAHcontrol on the Pi which gives me access through the CGNAT, so I can see how the 4 F@H Pi's are doing. I have a script to restart FAHclient on each F@H Pi in case the client gets in a tangle (daemon reload, restart). That's about all. The Pi's use little memory and swap memory is unused. Logs are kept in RAM and copied to the SSD's once a day.
Until a few days ago, I ran Boinc projects on those same PI's, too. Now I paused those all and will have to see, if there's any point in running Boinc as well. F@H was on 2 CPU's and Boinc on 50% (or 100% and they figure it out by themselves). As far as I noticed, both were doing OK for years, until I started the overclock experiment. There were never any warnings like 'hey, what you do is useless, I never finish in time ....'
I'm still on 7.6.21. Initially I wanted to know if I should upgrade my Pi's now or later and things like that.
Not really because of the heat generated by the Pi's is OK for me, at least in winter, but I did never paid attention to points received. I just keep the Pi's running their distributed computing tasks on their own VLAN and arranged for network access to them from the main LAN and from outside ('administrator' desktop and another Pi acting as an entry point to this LAN sitting behind a CGNAT). It's a hobby and I always hoped the DSC results are useful.
I've read about teams and resource groups, but no, my 4 Pi's just have been arranged in an cheap open tower construction (just pillars and perspex sheet) with 4 SSD's attached. It's good for cooling, but not so great for radio reception in this corner. No FM, no DAB+.
I knew from the start that arranging in a cluster is too demanding. They are all on their own. Originally three copies of the first one and kept 'in sync'.
I thought I don't have passkeys, but actually I do. Because of the impersonating thing. Not because of points. I never saw DSC as a competition.
I once tried Docker and stuff on a totally different Pi, or was it another of the same ilk, Home Assistant (?), but in the end I had to wipe it all out. Couldn't properly uninstall that fancy stuff, MQTT etc. etc. It was awfully complicated anyways. Always something left somewhere and 'phoning home'. It takes over the OS, more or less.
Overclocking (from 1500 MHz to 2000 MHz ondemand with over_voltage=6) initially seemed to work, but after one day it turned out to be unstable with F@H somehow. I have reverted all 4 Pi's.
An hour ago I started looking for a way to cancel a WU, and it seemed like there isn't/wasn't.
If you can tell me how to 'dump a WU' - may come in handy when fiddling with Pi settings and rebooting frequently - I'd like to know.
I use FAHcontrol on the Pi which gives me access through the CGNAT, so I can see how the 4 F@H Pi's are doing. I have a script to restart FAHclient on each F@H Pi in case the client gets in a tangle (daemon reload, restart). That's about all. The Pi's use little memory and swap memory is unused. Logs are kept in RAM and copied to the SSD's once a day.
Until a few days ago, I ran Boinc projects on those same PI's, too. Now I paused those all and will have to see, if there's any point in running Boinc as well. F@H was on 2 CPU's and Boinc on 50% (or 100% and they figure it out by themselves). As far as I noticed, both were doing OK for years, until I started the overclock experiment. There were never any warnings like 'hey, what you do is useless, I never finish in time ....'