I’ve never used a raspberry Pi before, any recommends on which one I should get? I’m looking to use it as my main node and farmer to save on power.
Definitely Pi 4. Don’t go any lower. You need it for the better / faster USB platform support. I doubt you will need more than 1GB RAM though, but I am not totally sure on that?
2 Likes
Be aware there appears to be some IO issues on the PI related to handling signage points of the full node because of the slow SD card access speed. Someone helpfully brought this to my attention in keybase (chat link here) and linked me to the github issue
If I was shopping for a pi for a node I would consider the Rock PI with built in NVME slot.
4 Likes
I’m using a pi 4 with 4 gb ram. Important to note that you need to use raspbian 64 bit instead of the default 32 bit installation that comes pre-installed.
I was notified on the IO issues too, but I’ve managed to farm a block on my pi with 10 plots. Moving the ~/chia to a USB drive seems to have reduced the IO issues based on the github page.
3 Likes
I am running mine on Rpi 4 2GB but haven;t noticed any… issues? I guess I need to check the logs closer 
You can now flash the RPI 4 to support boot from SSD on USB 3. I will move mine to my other RPI 4 4GB with attached SSD where I am running my HomeAssistant instance.
2 Likes
I am on a pi4 which boots from nvme, so no SD card involved.
I get the lookup problem occasionally,
Ie
especially when copying over new plots to the PI
I have multiple disks in an enclosure attached to pi using usb
I think I also get it more often if I have detailed logging on AND grep the log
1 Like
I came across this post today. I had done some experiments with a RPi3 (Model B+ 1GB RAM) already setup for home automation (Running Debian and Docker).
Tried to optimize by stopping all most all unwanted services/containers (for automation and the one’s in Linux), setup z-ram, copied databases to .chia folder to sync faster but you will not get a decent performance.
It is a no go on RPi3 for me.
1 Like
Very interesting! This means the Pi 4 is the minimum to farm. It is quite a bit faster than the 3, so maybe not too surprising?
Pi 4 is about 2× faster than 3.
Hi friend, are you going to use the home assistant and chia in the same raspbery pi? i’m thinking about doing this but i still don’t know how.
hey there - I stopped doing chia altogether but before I stopped I moved to a different laptop as the raspi was too slow and had a lot of disconnect issues.
As home assistant is too critical in my house, I don’t usually load anything on the same raspi. Hope that helps - cheers 
I wouldn’t waste my money on a Pi if your planning to run a full node! Way too many issues. Just grab a desktop with at least an i5 and 8-16GB of ram. If the size of the Pi is what you were after, check out Intel’s NUC line. I run my full node on a cheap HP Pavilion gaming prebuilt with an i5-11400 and 16GB ram. Never had ANY kind of issues in any of the dust storms!
Pi4 1gb is the minimum for the node.
Can’t go lower unless your just farming.
That being said I think the recent dust storms probably hint that you should be running something a bit better than a pi.
You know it’s possible if it’s just farming 
I think that you are wrong. People are scapegoating RPi 4 owners, and Chia is riding on that trend. This last dust storm was potentially done by some kid in his mom’s basement using just two computers and a script he downloaded from somewhere. You may ask yourself, what has been done in the code after the last dust storm to mitigate that type of attacks. What would happen, if that kid had a couple of friends working with him. You may ask why Chia is not doing a once a month official dust storms, just to assess the network health, test and improve the code.
During these past few days, a lot of nodes running on desktops were affected. One of the biggest misunderstandings is that when people see peers with 0 height, they assume that those are “slow” or “behind” nodes. However, that only implies that your own node is at the brink of falling behind, as it cannot fully handshake / get data from all those “behind” peers. The fact that there are other peers with “normal” heights is just because those peers have stale counters.
Actually, I was helping one guy with RPi 4 that got completely overwhelmed, and after dropping log level to ERROR, and reducing peers to 10, his RPi 4 started to sail smoothly (and he was not using all his cores!!!). Few hours after that, the chia official repeated that as what RPi owners should do. My i5 was initially affected, but doing the same things lowered that one CPU core usage from 100% down to about 10%.
One thing that is badly missing with chia setup is that there are no profiles, e.g., for RPi 4. Settings that are good for Threadripper and not really the same as for RPis. Also, a node that can crunch those transactions is a good node for the overall network, even if it only handles 10-20 peers.
And of course, the fact that chia code is basically choking one core, where all other cores are more or less idling just shows how primitive the code is. In addition to that, a lot of nodes were being killed by INFO level logs being generated at about 1 millisecond rate. This is just insane to prioritize logging over the core tasks (those logs were coming from the transaction crunching process - start_full_node).
And I am not trying to dismiss the fact that some (a lot?) of people are not that technical, and their setups are potentially not as good as they could be (e.g., running RPi on a slow SD card, running desktop on a slow HD, …). Another possibility for RPis is to run two or more of those (one RPi 4 for the full node only, and the others as harvesters, where even RPi 3 is good enough for a harvester). Another option that people will have potentially soon is Flex full node. So far, the promise is that it will run smoothly on RPis, as that code basically rewrites chia’s slow parts, and potentially correct bad approaches. I understand that Flex may have issues, but the choice will be up to the owners, whether they want to go with a threadripper, and be constantly told that they are missing something, or rather go with Flex farmer, and be done with that nonsense, as Flex will be addressing potential issues (they are fully committed to improving their code).
Another way of looking at that is that there are over 300k nodes out there. If Chia can reduce power draw by 10W per node, that is 300k * 10 W - roughly 3 MWh Is it worth to improve code to get that saving by asking one engineer to work on some of those problems for a couple of months? Things like fixing those logs is really a simple task.
Another thing is that we farmers have invested around $500 millions in just drives. On the other hand, Chia got $60 million investment in May. One solid engineer costs around $200-300k / year. Do you think that they have enough money to hire such guy (e.g., person behind MadMax or BitBlade, …).
Saying that, I would add that Intel Celerons that don’t have FPU are no go. Those are slower than RPis.
I recommend you Rpi4 8gb for a full node operation. Add SSD (self powerred) to allocate the main DB file.
Here you have “free -m” on my system:
pi@rp-4chia:~ $ free -m
--------- total used free shared buff/cache available
Mem: 7813 3637 90 35 4085 4018
Swap:1023 323 700
The system is currently using 3,6 gig ram.
Regards.
@xkredr59 Could you do a quick test on Linux, whether you can create a small (100-200 MB) RAM disk, and use it as a log folder?
farmer:
logging: &id001
log_filename: /mnt/ram/debug.log
I did install ImDrive on Windows, but chia was barfing, when I pointed to that drive. However, when I mounted it as another letter, it is working fine now. Yes, sure, on reboot all those files are gone, but during the last event, my log files (20MB) were worth around 5 minutes, so basically worthless anyway.
The reason for that is that we have basically three processes fighting for disc access during events like dust storm. The blockchain, the wallet and that retarded debug.log. If we move that debug.log file to RAM, both the blockchain and wallet dbs will have a bit more headroom during those events.
Maybe with that setting, some of devices that were struggling could handle those dust events a bit better (without much if any extra work or cost). It could also reduce the wear of a given device (maybe not much, though).
It may be also helpful on PRis, as those devices have limited bandwidth, even when having an SSD/NVMe, and the amount of RAM needed is really minuscule.
Wonder when the PI-5 will be released?
Pi 400 was the latest, there is no news at all yet on pi 5.