Get ready for a very technical response...
You probably want to remember this command so that you can run it when it's happy and during/after a longer print: Checking for throttling.
vcgencmd is returning a non-zero value for that then your Raspi is in panic mode and it's making adjustments to the CPU speed to compensate. One reason is power and another is heat.
This method won't tell you if attempts to read/write from memory are failing. This is more of a catastrophic thing in processing terms. These are categorized as
kernel messages. You could look for things in your logs related to this. Sometimes it's that the memory isn't available fast enough (think "overclocked too fast").
It might look like:
octopi kernel: <1-1.1:1.0: eth0: kevent 2 may have been dropped
cat /var/log/messages|grep kernel or also pipe that to
I'm guessing that this is the same as grep'ing for kernel above:
If you wanted to play with this theory:
sudo nano /etc/sysctl.conf and edit/append (from Debian man page and sysctl):
vm.min_free_kbytes = 16384
...or bump that to
sudo nano /boot/cmdline.txt in the kernel command line options to "disable the wired networking driver turbo mode" (noting that this suggests it only affects a wired Ethernet—related connection problem):
The kernel includes an on-demand governor which will bump up the processor's speed when it's under load. You might be able to slow down the processor's default speed with a
/boot/config.txt edit/append of
arm_freq=700 or whatever is lower than your Raspi's default. I just put the default for the non-plus version of the Raspberry Pi 3. Check out this page for inspiration, noting that you intend to limit rather than to overclock.
It is rumored that some of these problems are related to the double-powering of a Raspberry Pi and goes something like this:
- Power comes in on the standard micro USB port in the corner, as expected
- One or more of the USB connections also contains a 5V power line and that's also somehow being felt, creating a surging 5V feedback loop between both upstream/downstream power providers
Not that I love this solution, but some people are applying tape to the superfluous 5V USB pin.
I note that the
vm.swappiness value in Raspbian has changed since sometime in 2016. If I now run
sysctl vm.swappiness I get
vm.swappiness = 60. From what I understand, it used to be
1 before this, which meant "almost always avoid using swap". So now presumably, it uses swap significantly more than what it did earlier. What does this really mean to us?
If the speed of the micro SD card is low (typical of the bargain basement cards I buy) then this means that if Raspbian is swapping memory to disk more frequently, that becomes a bottleneck.
You can use
free -h to see how much swap is being used.
total used free shared buff/cache available
Mem: 875M 131M 500M 6.6M 243M 686M
Swap: 99M 0B 99M
But if I've got a cheap/slow microSD then that's not necessarily a good thing.
watch vmstat to get a feel for this in realtime, especially while a print job is running. Compare with what this looks like while you're streaming video back to your browser, etc.
Shorter version of this section: replace your microSD with a really expensive one or adjust the
vm.swappiness back to
sudo nano /etc/sysctl.conf.