dmacias

I'll have to update tmux

Basically yes but it's a little more complicated than that. The script is written in php with a main while loop and a couple nested loops. One for the fans/commands. One for the polling time which is a variable loop based on polling time but fixed at 10 sec to check the fan config for changes while waiting. E.g. It sleeps for 10 sec then loops 6 times to create a minute. I would need to carry a global true/false hdd poll and sensor poll and maybe a couple counters to count the time through the main and nested loops. So when time is reached, poll is true. It becomes more complicated if someone were to set the hdd poll less than the sensor poll. I could limit it in the settings or deal with that in the script. I'm not sure of the impact from reading ipmi sensors and setting the ipmi fans every 10 secs. I have seen it choke on too frequent commands. This could lead to the unRAID webgui becoming unresponsive waiting on ipmi commands to render the Settings and Readings pages or the whole webgui waiting to display the footer. It could also error out and not display anything. There could be problems writing config files with the editor. All that said, I'll see what I can come up with but there may be some side effects on shorter intervals.

I not sure what you mean. For hard drives, smartctl can impede drive performance if run too often. CPU and fan speeds both use freeipmi to get and send to the BMC. Which can lock up and not respond.

Im using a Powerful Intel Xeon E3-1245v6 CPU with a TDP of 78W and I can confirm fast temperature spikes. That's a good use case. We've had some discussion in here about this but I believe FANA, FANB.. are for peripherals including hard drives. And when set to auto are controlled based on system temp. FAN1234 are based on CPU temp. I was going to ask what the temps are when set to auto and which mode (high I/O, standard, optimal). But if your CPU is on FANA then that wouldn't work. It mentions the same thing in the link. Thanks for that. I hadn't read that one. It has a good idea about setting the mode first to keep the BMC from changing the fan speeds. Very thorough write up. I may be able to just add a hdd polling time and then add back the 10 sec intervals below 1 min. But still need to be careful about too many ipmi commands.

That temp is the highest hdd temp pulled from from unRAID webgui. It may differ depending on when it was polled and when the webgui actually pulled it from the hard drive.

That could lead to a similar problem by hammering the ipmi. It could freeze up the IPMI Settings/Readings pages and possibly the entire webgui if you have temps and fans in the footer. I have had this happen before when an ipmi command hung. My question to you would be what use case would you need such fine control over the CPU fan? Is there a situation where the temp is going to rise that dramatically in less than a minute. The fan should already be spinning and cooling to some degree. It might have a small spike in temp but should even out. The way the fan control its written right now it would be difficult to add this. The highest hard drive temp is injected as a sensor when I get ipmi sensor readings. So it shows up like an ipmi sensor. I wrote the fan control script with the mindset to minimize executions. It won't execute if the pwm is the same when polling. I also have it round the (% value x 16) then x 4 to get the pwm instead of just rounding x 64. Partly so it won't execute when a value changes just 1 point and goes from say 30 to 31 then back to 30. It needs to go to 32 or drop to 28. This then creates a +/- 4 in accuracy. So if you were to run it at a smaller interval, it may not even change anything. I would say run it a little longer and watch the fan log.

That's what I thought. Thank you for clarifying that. I run both tunable and fan control at 3 min intervals.

There's a beta version in the OP. I'm moving it to its own repo. So when I was ready I was going to update the CA version to point to the new repo (IPMI-unRAID). Maybe you could shed some light on the issue in the post above. The plugin webgui uses unRAID vars to get the hdd temps but the fan control script uses hdparm to check standby and then smartctl to get highest temp. Could intervals of 10, 20 or 30 seconds cause problems.

I pulled the update. There should be a new update reverting the changes. I need to investigate more the impact of running the fan control script in intervals less than a minute. The script uses smartctl to get the highest drive temp. I was starting and stopping the script a lot, testing some settings and apparently one of my parity drives got a sata error. I didn't notice this till this morning after the mover caused parity errors on that parity drive. I'm not sure if they are related but I decided to pull the update till I can look through the logs. Also check why I wasn't notified till the parity errors. I would like anyone using the beta to update just in case.

Unless you lower the thresholds of the fans on the Supermicro, they will spin up to full if they fall below the threshold. I changed Temperature Polling Times to seconds and added 10 sec intervals below a minute. Everyone will need to change settings, save and restart fan control otherwise the polling will be 6 times less. So 1 min = 10 sec. I added fan max speed. Didn't see the edit about the network connection change and fan control. I'll fix that on next update.

Forgot to remove the tablesorter package. It uses a cdn link now. It's fixed now.

Thanks I fixed the link.

It's for the beta. I won't update the old repo except to update the plugin file to point to the beta/new repo. 2017.06.21 The update was to fix the auto setting and to return the fans to the previous mode set in the BMC.

Do you have a manual host set or is it auto?

Yes that's the way the fan control has always been. The original point of the plugin's fan control was to control the side fans of my case based on hdd temps especially during parity checks/rebuilds.

I wouldn't worry about it. If it's working fine. My manual looks just like the picture you posted but says nothing else. I was just going off other manuals and the faq. I was just worried it might be running off system temp instead. Anyway I did more testing and research. Setting a value of 00 for the fan isn't Auto. The board just kicks the fan up to full speed when you set it too low. I now have to Auto setting or 00 value do nothing in the script. So it will use whatever Mode you have set in the BMC. I'm using this command to set the fan speeds "ipmi-raw 00 30 70 66 01 00 XX" XX=00-64, 64=100%, 32=50% Also when the fan script is stopped it resets the fans to the mode you selected in the BMC. If the FANA stuff wasn't confusing enough the modes are too. 00 is Standard 01 is Full 02 is Optimal which is lower than Standard 04 is between 00 & 01 I'm using this command for this. "ipmi-raw 00 30 45 01 XX" The one thing I am wondering though is even though the fan script is changing the the fan speeds does the BMC use the Mode to adjust those same fans at some point.

I'm not sure. I see what you mean but I'm not sure 1-4 = system and A = CPU. I got this from their fact. I know its from a different Motherboard but I have seen similar. Sometimes it seems like there's some conflicting info. Question We have a X9SCL-F and connected Chassis fans to FAN-1/2/3 and CPU fan to fan header "A" on this mainboard. Now we see that the fan spin up/down, or sometimes full speed. What can we do? Answer FANA is for add-on card and controlled by system temperature. FAN1~4 is controlled by CPU temperature. CPU Heatsink fan should not be connected to FAN-A. CPU Heatsink fan can be connected to FAN-1. Chassis fans can be connected to FAN-2~4 or FAN-A.

Also if anyone who tries the beta above wants to go back you can just uninstall it and install the plugin from the OP.

The FAN1234 is just a the group. The fan speed that is shown is only for the first fan available I the group. That's why hiding the other fans shows rpms. It's really just a reference and is never updated unless you refresh the page. I was thinking of just picking the highest or getting rid of it altogether. I need to double check the auto to make sure I'm using the right value. But auto right now sets a value of 01. Edit: 00 or 01 does not equal auto. 00 is auto for ASRock. You also might check your manual but I'm pretty sure FANA is for I/O but not sure what temp sensor it's based on. I believe FANS 1, 2, 3 & 4 group are based on cpu temp. There was some discussion a few pages back.

If someone with a Supermicro X10 or X11 wants to give it a try here's the latest beta I've been working on. It is fully functional. No bugs or issues that I know of yet other than I'm still working on ASRock dual cpu support and Supermicro X9 support. So fan control will not work for a X9 board yet. This is a new separate repo I split from my unRAID plugins repo and when I feel this is right I'll push an update to the main repo and point it to this one. https://raw.githubusercontent.com/dmacias72/IPMI-unRAID/master/plugin/ipmi.plg

Did you get the same delay on chmod or chown? I might of just had way more events than normal use or too many small files. You could use something like this to check permissions in the firstrun script if they've changed stat -c '%u%g' /var/cache/zoneminder/ == '033' or stat -c '%U%G' /var/cache/zoneminder/ == 'rootwww-data' stat -c '%a' /var/cache/zoneminder/events/ == 777 or 755 whatever the value is supposed to be

I also updated the plugin for 6.4 themes and moved to a separate repo of its own. I pushed an update to the old plugin repo that will point to the new. Any subsequent updates will come from the new. So even if you install the old plg link it will install from the new repo. Maybe @jonp could change the link in the OP. https://raw.githubusercontent.com/dmacias72/unRAID-NerdPack/master/plugin/NerdPack.plg

I add xinetd.

Thanks. I figured that out from the run script on your github. Yes it was taking that long, even when I ran the chmod and chown from the unRAID command line also. I purged all the events and switch to ext4. I also increased my post buffer (15sec x 20fps) a bit more to get longer/less events. May need to adjust sensitivity. Thanks for the filter suggestion. I left the purgewhenfull but have it set to 75 (in case the hard drive gets full). I created a separate filter PurgeByAge using -14 days.

I'm not sure what was wrong with the permissions. The owner was correct and the write permissions were drwxr-xr-x. The only problem I see is, if there are a ton of events it could take a while for the docker to start since the data directory is chmod and then chown. I had a ton of events and was using an xfs partition. It took more than 20 minute to start. I wiped the events and formated the drive to ext4. I don't think anything needs to be fixed. Just sharing my experience.