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.
If 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 grep kevent
I'm guessing that this is the same as grep'ing for kernel above:
cat /var/log/kern.log
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 32768
.
Additionally, 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):
smsc95xx.turbo_mode=N
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.
Try also 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 1
with sudo nano /etc/sysctl.conf
.