# MCU discconnecting, rpi not respoding

**URL:** <https://klipper.discourse.group/t/mcu-discconnecting-rpi-not-respoding/9096>\
**Category:** General Discussion\
**Created:** [June 22, 2023, 5:04pm UTC](https://klipper.discourse.group/t/mcu-discconnecting-rpi-not-respoding/9096 "2023-06-22T17:04:51Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![Piezo](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/piezo/32/1110_2.png) [@Piezo](https://klipper.discourse.group/u/Piezo)\
**Post date:** [July 3, 2023, 2:04pm UTC](https://klipper.discourse.group/t/mcu-discconnecting-rpi-not-respoding/9096/21 "2023-07-03T14:04:10Z")

</div>

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](https://github.com/Klipper3d/klipper/issues/951).  
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](https://github.com/Piezoid/klipper/commit/b1544159f) 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`:

```auto
[Manager]
CPUAffinity=0,1

```

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

```auto
[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.

---

<div class="post-metadata">

**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\
**Post date:** [July 3, 2023, 8:17pm UTC](https://klipper.discourse.group/t/mcu-discconnecting-rpi-not-respoding/9096/22 "2023-07-03T20:17:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\
**Post date:** [October 26, 2024, 5:57am UTC](https://klipper.discourse.group/t/mcu-discconnecting-rpi-not-respoding/9096/23 "2024-10-26T05:57:27Z")

</div>



[Previous page](https://klipper.discourse.group/t/mcu-discconnecting-rpi-not-respoding/9096.md?page=1)