Fanshim causing noticeably INCREASED Pi temps at idle...

[adamburgoyne]

I've had the fanshim fitted and enabled ever since I purchased my Pi4, I originally had it set on quite high thresholds so it rarely came on but it did work as expected when it did. Yesterday I disabled the service in order to change the values and forgot to re-enable and much to my shock when I checked Grafana later in the day my Pi had been at it's lowest ever temps since the shim was disabled! Instead of averaging around 50 degrees it was around 41 - 42 degrees which is quite a difference.

I've attached the graphs where you can clearly see the drop and rise within the minute of my restarting the fanshim service with the below command. I've done it several times since in order to confirm and it's obviously the fanshim service causing this but I'm not sure why.

Edit: As per comments, the exact same outcome if delay is set to 10 or even 60.

  sudo ./install-service.sh --on-threshold 53 --off-threshold 49 --delay 2

  Setting up with:
  Off Threshold:  49 C
  On Threshold:   53 C
  Delay:          2 seconds
  Preempt:        no
  Disable LED:    yes
  Disable Button: no
  Brightness:     255

Is this a known issue as otherwise it seems like I'm going to be overall better off with swapping the fanshim for a cheap basic heatsink if it's going to be at least 9-10 degrees cooler without it!

You can see the obvious dips and increases where I've disabled/enabled the service here:

https://imgur.com/a/cPufYeW

[Gadgetoid]

I wonder if firing up and doing something every two seconds is just often enough to prevent the Pi frequency scaling from kicking in and downclocking the CPU.

You could try graphing the output of (I think) cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq and see how it correlates in both cases.

I'm not sure there's a fix for this outside of moving the fan control into a kernel module, or leveraging an existing kernel module to handle it. A Python script is a flexible but somewhat crude and detached way to handle fan control.

[adamburgoyne]

I'll have a look, will also try a higher delay and report back. Unfortunately if it can't be fixed I'll be better off removing the fanshim all-together and fitting a small heatsink to the CPU. It's unlikely I'm going to get 10~ degrees of cooling with the fan enabled so seems a bit counter intuitive to keep it going.

[adamburgoyne]

Upping the delay to 10 or even 60 still has the exact same effect. Temperature shoots up by the same 9 - 10 degrees and stays there until disabled again.

I'm not sure how useful this is but here are two graphs of the cpu freq and temps. Sorry I'm not that familiar with the frequency stats or Grafana to combine or to make much meaning from these. I can't see any correlation between low temps (fanshim service disabled) and high temps (fanshim service enabled) when it comes to the CPU freqs. Let me know if other info would help.

https://imgur.com/a/qlFOLBf

[grayerbeard]

I would suggest the check every 2 seconds is far faster than needed. 10 sec would be fine. Also the service etc structure seems over complicated for requesting a temp reading and operating a GPIO output. These observations seem to show that.

I have now removed my fanshim because it has stopped working with my PWM version and instead I have fitted the large pimorini heatsink. So far I have seen no high temperatures.

The fan had been in continuous use many months.

On Tue, 16 Jun 2020, 09:54 adamburgoyne, notifications@github.com wrote:

Not had a chance to map the frequency over the temp but upping the delay to 10 or even 60 still has the exact same effect. Temperature shoots up by the same 9 - 10 degrees and stays there until disabled again.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pimoroni/fanshim-python/issues/84#issuecomment-644630507, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUCWEJUFTFRHIK7Y75X2Q3RW4XLNANCNFSM4N7LJTNA .

[adamburgoyne]

Yeah I just assumed the check wouldn't really be very intensive so the faster the better, but as mentioned there's no change between it being 2 or 60 regardless.

I'm just surprised this hasn't been flagged as more of an issue. Literally the opposite of what the product is supposed to be doing! I'll probably swap out to a heatsink too, if it's sat at 40ish with a disabled fan over the top I can only imagine I'll get a little more heat off with a heatsink on too.

[druck13]

On 16/06/2020 08:50, adamburgoyne wrote:

I've had the fanshim fitted and enabled ever since I purchased my Pi4, I originally had it set on quite high thresholds so it rarely came on but it did work as expected when it did. Yesterday I disabled the service in order to change the values and forgot to re-enable and much to my shock when I checked Grafana later in the day my Pi had been at it's lowest ever temps since the shim was disabled! Instead of averaging around 50 degrees it was around 41 - 42 degrees which is quite a difference.

When the fanshim service is disabled the fan is on all the time, so the temperature will be lower. When you set thresholds, the fan may only come on at a higher temperature, so the average temperature will be higher.

Note the title of your post is misleading, its not the fanshim causing higher temperatures (compared to no fanshim), but having the fanshim service active with your current settings.

You've got two choices with the fanshim.

1) Set the on threshold quite a bit higher than fan off idle temperature, but lower than where throttling occurs, and off threshold around fan off idle temperature. The fan will be off most of the time, but kick in to maintain performance.

2) Set the on threshold lower than the fan off idle temperature and the off threshold less than the fan on idle temperature. This effectively keeps the fan on all the time. It will keep the Pi at the lowest possible temperature, but this is really necessary and may cause the small fan to fail (I've had two go).

If you just set arbitrary on and off thresholds, just above and below the fan off idle temperature, you'll find Pi just cycles the fan on and off every few minutes, and the average temperature is between the two set points.

---druck

-- Email: druck@druck.org.uk Phone: +44-(0)7974 108301

[Trotter73]

Hi,

Before you ditch the shim try this.

Disable or remove the python service and then add the following to your config.txt

dtoverlay=gpio-fan,gpiopin=18,temp=60000

Replace the 60 for whatever temperature you want the fan to be set at, the LED effects will be missing but I suspect you will see the lower temps you saw with the service disabled...

[ednl]

When the fanshim service is disabled the fan is on all the time, so the temperature will be lower. When you set thresholds, the fan may only come on at a higher temperature, so the average temperature will be higher. Note the title of your post is misleading, its not the fanshim causing higher temperatures (compared to no fanshim), but having the fanshim service active with your current settings.

@adamburgoyne Was this a correct assessment? Was the fan simply on all the time when you had disabled the service, causing the lower temps? Because I think this would be the normal case, yes. Otherwise this would seem like a rather important issue.

[adamburgoyne]

Hey sorry forgot to get back to this. Yeah more or less, I assumed the fan would be disabled if I disabled the script but thinking about it that was a silly assumption! The decreased temp was obviously due to it constantly being on and I just didn't open the case up to see why.

I've got it around 49 now with the correct values on the service at least. Thanks all!