Sharing RPI between OctoPrint and Klipper

Hi,
About 6 weeks ago I switched from Marlin to Klipper. Back in May 2018 in this thread Problem after installing Klipper (after disabling IPV6 on RPI) @OutsourcedGuru brought up a very good point

It would be great to eventually come up with a how-to for updating Marlin and OctoPi for Klipper. I know from second-hand experience that it moves enough of the work over to the Raspi 3 so that the RAMPS board is never overloaded (resulting in short-duration stalls which themselves probably produce surface blobbing).

I can confirm that I am observing "short-duration stalls which" "produce surface blobbing". This issue is caused by the fact that Octoprint and Klipper are sharing resources and even RPI 3 B+ is not always able to serve both in real time. The workaround is to lower printing speed, but then it takes away one of the main advantages of Klipper – ability to print much faster than firmware running on 8bit MCUs.

So, here are few questions, I’d like to ask, and I hope other Klipper users can also benefit from the answers:

  • What can be done, if anything, to increase priority of the processes running Klipper, while keeping OctoPrint functional?
  • Which core elements of OctoPrint cause the highest CPU load and/or disk/memory utilization during printing process? Which of them are optional and can be disabled?
  • Which Plugins are the most “resource hungry” during the print?
  • When client is connected to the web interface, does OctoPrint “feed” all the tabs with the data, including the tabs that are currently hidden? For example, is it sending video stream to ‘Control’ tab if active tab is ‘Temperature’?
  • Is there a way other that “try and fail” to find out whether certain newly added OctoPrint feature or newly installed Plugin will affect print quality due to RPI temporarily running out of resources?

Thanks
Best regards,
Boris

Noting that I've not installed Klipper myself yet...

I thought I'd mention my initial Klipper post and this and this on the related OctoPrint issue.

Priority: In UNIX, there's a nice command, as in renice {priority} pid where {priority} is a number from -20 to 19. A lower number is nicer to the other programs on the system if you can think of it that way. So you might try increasing your own ID's priority rather than clobbering or changing OctoPrint's.

CPU load: Follow the last link here in my post and scroll down to the htop discussion. It won't tell you which is which (as much as I'd like) but it will show you how what you do affects the amount of memory available. I might suggest that turning off the webcam is a great way of knocking down the CPU requirements as well as avoiding browser screen reloads/refreshes which are guaranteed to push a single core to 100% for a bit.

Hungry: Have you tried walking through your add-on plugins and disabling them? Anything that hooks into the GCODE stream would be the first I'd try (Octolapse, for example).

Does OP feed all tabs? Probably "yes". In your browser's developer console, review the Network tab. "If a tree falls in the forest and there's nobody to hear it, does it make a sound?" In this case, they're just feeding DIV tags which are hidden. So the DOM is there to hear the tree falling, in other words.

Monitoring print-streaming success/bottlenecks: we've been talking about this.

Thanks. That's a lot of reading; I am just a half way through, but have already found valuable info like disabling serial and BT.

In UNIX, there's a nice command

Heard about 'nice' but never used it. Will keep it as the last resort, if other options won't be enough.

Have you tried walking through your add-on plugins and disabling them?

Yes and No. I disabled all plugins, camera and code viewer while troubleshooting the issue reported here https://github.com/KevinOConnor/klipper/issues/1112 Once the cause of failures was identified, I re-enabled camera and couple of plugins, but should probably go one by one while printing the same test object.

In your browser's developer console, review the Network tab.

This is very good suggestion. I did not think about it.

Thanks

That's controversial, btw. It is suggested by others that UARTs have nothing to do with the communication.