Would a node-red or mosquito installation running in the background hinder the octoprint process?
Just responding to this thread, because of "new" activity" apparently.
Sorry for not being able to directly attribute which hardware change "made the difference", but I threw together hardware I had laying around: A Rpi4/2Gb and an NVMe 128Gb SSD in an USB3 enclosure (yes, only using 2%, but the SSD came from a dead notebook).
I could burn the octopi 0.18.0 image straight to the SSD and boot from it. After that I restored my octoprint backup and it ran. (So under Python3). It also streams two USB camera's: One "cheap chinese" endoscope at 640x480, and a logitech C920, at resolution 1920x1080. The Rpi is connected with its a wired gigabyte ethernet port. Not using its WLAN.
I am not mentioning this to recommend this specific combination of hardware, but just to describe what I am using.
The perceived performance compared to my previous Rpi3 / SD-card based installation is notorious. The interface comes alive fast. The web page loads noticeable faster. I can now upload big GCODE files mid-print, without any noticeable effect to the extruder movement. When I look at the resource monitor (through its plugin) and with two screens open (one for each camera), the CPU load remains low. Big files are arc-welded during print, and files become available for printing seconds after uploading.
For me, it is just a so much nicer user experience, so I am at the point that I continue with this, without the urge to see "what could be left out". I would definitely recommend the Rpi4 and possibly see if SD / SSD makes another difference, in case you are not happy with the performance and are using an SD card.
The best way to find out it to monitor its resource usage, to see whether you hit bottlenecks.
The price, in the UK anyway, is the same so shouldn't the question be "Why wouldn't I use Pi4 for Octoprint?".
On a RPi3B+, allthough the Ethernet chip is gigabit capable, the connection from chip to SoC is still via USB2.0, which limits that bandwidth available to 220-250Mbit/s. This is still better than the 100Mbit/s for a Rpi3B.
I decide based on this 3 categories.
The pi3 runs cooler as the RP4 and is good enough for octoprint +1 cam
I use the pi4 if i need more than that and the pi hat.
if not
i use a intel ( Bay/Cherry Trail / Braswell or Apollo Lake) board with a picopsu.
actually it consumes around 20w with a dual tuner dvbs2, 4GB ram, 1ssd for the os in it.
Runs 4 instances, 3 cams, 1 vdr, and the unify controller software. And without the dvbs2 card it was much cheaper than a raspberry pi4 with case and power supply.
In the early Pi4 days, there were concerns on overheating and subsequent down throttling. I do use a housing with passive cooling. The temperature is not a concern with current firmware and the octopi 0.18.0 image for me.
My Pi3B+ cannot keep up with webcam processing in higher resolutions. One cpu core is 100% all the time and streaming (via octopi web interface) isn't great.
serial.log from octoprint slows things a lot (like 5h print becomes 7h print) and it's crucial for debugging of some problems. I would love to have it always enabled. With 4GB rpi4 I could just log into tmpfs (ram based fs) and don't care. Hopefully there will be no time penalty with such setup.
So 3b+ is not always enough. But didn't test if 4 will perform better. Don't have spare 4 yet - waiting.
I would say if you can go with rpi4, go with it. If not, 3b+ is not a bad option.
I don't because it turns out that with writing to serial.log on sd card on rpi3 slows things so badly that even layer shifts happen.
But I would like to have it always enabled and be able to go back and see what happened when needed.
When (or "if" these days) I get raspberry pi 4 I'm going to put serial.log in ram and see if it works without problems.
The writing speed depends on the speed of the SD card and not that much on the calculation power of the SOC. In this case, a RPi4 wont give that huge advance.
It's a good reason Gina mention this:
If you have constant issues, maybe fixing them takes away the need for a constant serial logging.
Also, without serial.log, in case of an communication error, in the octoprint.log the last lines of the serial communication are stored.
Rpi4 is to have 4GB of ram so serial.log can be in ram and not on sd card.
Constant issues are easy because they happen... constantly. Debug log is useful for these rare or intermittent issues.
And I'm not talking about communication issues but issues like
So for one issue that can occur at the start of the print you are logging the complete print?
I'm logging (or rather I want to log on rpi4 to ram) because issues exists and without logging I get no valuable information at all. And hopefully on rpi4 + ram - logging will be fast and not problematic, so there will be no point in NOT logging everything.
Anyhow: Logging if for tracking bugs down, not to keep the alive.
But if you really want to log all, the I recommend something way more powerful than a Raspberry Pi.