MCU discconnecting, rpi not respoding

General Discussion
21

You should keep the default CPUSchedulingPolicy=other and only use Nice with caution. Real time processes can block the whole system until they yield. RT schedules should be reserved for threads running real-time code, engineered to yield as soon as their work is done. A python interpreter is the opposite of that.

Personally I do set a Nice= level below zero. However, one issue is that it sets the priority of all klippy threads, some of which handle background tasks, see here.
Ideally klippy should use setpriority(2) on the background threads. Something like nice = -20 < C serial thread < Python serial thread < main thread < background logger < 0. The locations starting the threads are highlighted in this patch that sets the thread names for profiling purpose.

Another trick is to restrict all the system process to one or two cores by putting in /etc/systemd/system.conf:

[Manager]
CPUAffinity=0,1

And then in klipper.service, whitelist the other cores:

[Service]
CPUAffinity=1,2,3

That way cores 2 and 3 are reserved for the klippy process. I share core 1 with the other processes as I think it might be beneficial for communication with moonraker, but I havenā€™t conduced enough measurements (with perf sched) to be confident about it. The smp_afinity of the USBā€™s IRQ can also be set to the klippy only cores.

Just to clarify, at this point, these are not recommendations but merely experimental tweaks Iā€™ve tested in my own environment. I havenā€™t even formally demonstrated that they do not have any negative effects.
I run tests with down-clocked cpu to 480MHz (cpupower frequency-set -g powersave), loading them with openssl speed, while I test the max speed on two steppers at 128 microsteps. I have not yet found a way to measure the tightness of klippyā€™s deadlines without running it to its limits.

6 Likes
22

Maybe adding to @Piezo excellent answer:

I have been running Klipper on a RPi 3, RPi 3 B+, RPi 4, Orange Pi 3 LTS and Banana Pi M5.
Typically, with either Octoprint or, in more recent times, with Moonraker, Fluidd and Klipperscreen.

So far I did not have any issues with the computing power of these platforms and ā€œTimer too closeā€ is one of the errors I have had only once with a dying SD card.
Although, I have never used a webcam and Iā€™m trying to avoid multi MCU scenarios and rather went to boards like Octopus and Spider.

If running these boxes dedicated to Klipper I would think that they are sufficiently powerful and should not produce any errors. Things I typically make sure:

  • High quality dedicated power supplies
  • Tune the power supplies to 5.1 V when fully loaded
  • EMI filters, e.g. all my SSR controlled heat beds have an own SSR EMI filter
  • Bit of EMI minded cable management, e.g. routing, shielding, grounding
2 Likes