Open thomasbrooks4 opened 2 years ago
Hi, Thanks!
Well it should be doable. Actually that's a good feature idea for the script in general, taking drive temps into account in an offset modifier. From there, an alternative mode using them as primary temp source is doable too.
For that it shouldn't be anything harder than pulling drives' data temps from something as basic as smartctl -l scttemp /dev/sd#
with a grep.
I'll give it a shot when I have some time.
Ideally I would have considered including modules to pull GPU data too from AMD and Nvidia cards, but atm my R720 isn't fitted with a GPU anymore, so I can't really test it.
For the time being, you can see that the ambient mode and the delta mode pretty much give you the option of driving fan speeds solely from inlet and exhaust temps, eventually taking into account the difference between the two. Keep in mind also that even using CPU temps as temperature source, the script still use ambient (inlet and exhaust) temps as modifiers, adding a positive offset to the CPU temps to ramp fans a bit higher when the environment justify it.
On an other note, for my R720 when I still had a GPU living in it, I did used some plastic sheet to make a duct/shroud, so the GPU wouldn't fry the 10gbps SFP+ NIC in the neighboring slots. On top of that little new feature for the script, a bit of modding can do wonders at times too! Important note though: don't make a duct to funnel more air up to the drives' back cage, because in doing so, you might deprive from too much cooling the PSUs.
That would be amazing, yeah I know for the same principle it could be nice if you could design it in a way where we can just add temp values from different sources as part of the main calculation, so in theory the same block used to add smartctl
temps I could then add something for the 1070 with something like this (https://askubuntu.com/questions/34449/how-to-see-the-video-card-temperature-nvidia-ati-intel). However, a concern I am actually realizing is my need is moreso for the OPPOSITE of what this is supposed to do honestly. Every IPMI fan script I found was for making things quieter, which isn't a problem for me, the main problem is, the built in fan controllers go off of CPU rather than other temps, so I would rather set a fan curve for custom data (such as drives or GPU temps). Because now that I'm diving deeper into the logic, if I'm understanding this correctly, you are basically taking the temps and if things are lower then they need to be, you ramp down the fans, otherwise you set the control to auto so it can take over. If that's correct, in my case the auto setting ISN'T enough since it's not factoring in the drives and the GPU, so ideally taking this script further to ramp UP on higher temps would be ideal for me, but that might be asking too much.
Well, quick break down for when using CPU temps:
The reason then it works not as a 'trigger' but an 'until' is that, yes primarily the point is to keep temp speed as low as possible, so it check if temps are still under a threshold; but it's also so then the last temp step of each curve is automatically defined as the breaking point temperature beyond which the server is handed hardware control back. The only time my servers, in the last 3 years, actually broke any of the in-place thresholds/breaking points, it's when the air conditioning died while the mechanical ventilation was still out of order too.
If it can be of any use to you in the mean time, do notice that the script counts itself the number of steps in a curve. So if you want to add steps to curves, for finer control or more extreme temps, you can, it will dynamically take them in account and use them so long you made them properly. Even if the point of the script was kinda to silence servers as much as possible, nothing stops you from bumping up the value of each FST# step, and/or adding steps above 75°C that would all be at with a FST# value at 100 (so full speed). You can literally use the script to make your server a 24/7 jet engine if you feel like doing so.
Know also that in the server's BIOS and Idrac interface, you can define the hardware profile to be way more aggressive, which would make it not an issue for the script to hand the control over back to the hardware.
I have started the "wip" branch, just took notes and todos for now in it, and amongst these todos I do plan to write a function for the temp/curve comparisons, so it would become way easier to create new profiles/modes, and so adding other temp sources further down the line will be easier too. I may even create a "blank" source with ready-to-go logic already done for some other use.
any update to this for using unraid Hdd temps
Hello! Major props to all the work you have put into the script, exactly why I was hoping to get your help since I'm sure you will be much quicker in understanding how to modify for my needs. If you can't spare the time, I totally understand!
Ultimately, I am running Unraid on a r720XD and managed to shove a leftover GTX 1070 (for boosted VM usage and video transcoding). I have 2 cache drives in the back of the machine as well and I have an issue that when the 1070 is under usage it causes a lot of excess heat in the back of the machine. The CPU temps are low so overall the fans barely run, then I start to get heat warnings on my back drives. Ultimately I'd like to tie these fan curves to specific Unraid disk temps or potentially GPU temps. I am fortunate enough to have my server in my garage so I also don't care about sound at all, I'd be happy to kick it up as high as it needs! I understand the fan curves section and I guess I can bump up the curves to higher tolerances, but ideally I could add in "external" temps to factor into the fan curve steps.