gmk2

Yep. Here is a sample of my log that shows the fan modulation: 2018-08-17 13:46:10 Fan:Temp, FAN1234(94%):CPU2 Temp(48°C), FANA(89%):CPU2 Temp(48°C) 2018-08-17 13:47:11 Fan:Temp, FAN1234(93%):CPU2 Temp(46°C), FANA(86%):CPU2 Temp(46°C) 2018-08-17 13:49:11 Fan:Temp, FAN1234(92%):CPU2 Temp(45°C), FANA(84%):CPU2 Temp(45°C) This is on an X9 board per earlier posts. You can see fan rate modulating with temperature on both fan headers.

That is right (it won't work). Currently Supermicro support is enabled for X9 and the X10/X11. You would need to identify the raw ipmi commands for an X8 to have them incorporated into the plugin to get the X8 supported (assuming they are available).

Hi Xuvin, Your fan minimums are way way too low. at 1.5% pwm your fans will not spin at all and your going to be hitting the fan thresholds and the board will override fans to 100%. Try starting at 65% and see what rpm you get. PWM is not linear with RPM. Cheers, gmk2

For the plugin to work your fans need to be set to "high" as this stops the motherboard fighting to control fan speed. Essentially you need to pick to either use one of the 'out of the box' fan control levels from supermicro OR use the plugin. Out of the motherboard typically CPU temp drives fan headers 1-n and the PCH will drive Fans AB provided your using PWM fans. One of the value adds of this plugin is to be able to change this up; my board is a dual cpu board and I have different fans for the cpu coolers to the case fans. From this use case using Fan headers A and B for the CPU and setting the plugin to drive Fan AB off CPU temp is a good solution. For the case fans I have Fan 1 through 6 - and these I have set on HDD temp. I expect in normal use my board is jammed into a very low U case with a set of tiny screamer fans cooling the whole shooting match. I have also entertained a possible enhancement to fan control to allow a secondary / override temp control for each fan. In my scenario the CPUs when working hard can produce a lot of heat and this is all behind the HDD. What this means is that a high workload on CPU would ideally drive both the CPU fans and lift the case fans. If implemented I would picture that you would want to define two temperature ranges and two min and max fans against the one fan header, the logic would be to take the higher fan pwm calc out of the two so if the HDD are hot it can spin up the fans and if the CPU is hot it can also spin up the fans.

If you click readings you should see your fan rpm. What is this showing when you apply these settings? If you then click events you should get a log - this is where you will see if threshold is being tripped.

Do your fans drop down from max when you enable fan control before roaring back to full noise? If so this is likely the classic supermicro fan speed falling below threshold forcing max fan speed.. With 50% PWM and your now increased lower thresholds you may be doing exactly this. You can check the ipmi log to see if it is logging threshold events, and check the sensor readings to see the actual fan rpm (rather than the config). If you want to adjust your thresholds, set your fanmin to 85% and see if the rpm fall from max. Check what the rpm value is. Progressively change the fanmin down by 10% and check the rpm and you should find the threshold point. Unless the PWM% is low enough for your need this may be a trigger to drop your thresholds. For me, I looked up my fan specification and set the thresholds 150 rpm below. The threshold is intended as a safety feature in case the fan control doesn't apply enough PWM to get the fan to start, its not intended to define the minimum rpm you want to run the fans at. It does take a little tweaking to get right. I have a few pages in a notebook of trialing PWM % settings to see what rpm my case fans vs cpu fans returned. Good luck.

Hi cyriouslydylan, Your minimum fan setting for Fan A is way way too low - at 15% I'd be suprised if the fan even spins. Remember the % is of PWM and PWM doesn't equal RPM. You need to set this up to something more realistic - start with 50% PWM and check what rpm you get.

I don't have a github account - you need to keep the two statements above the one I modified as it still relies on the min / max rules outside of the templo to temphi range. No rush

Hi dmacias, Can I make another request? I've had a look at the fan control logic and essentially what it is doing is saying: - if the temp is <= templo apply fanmin - if the temp is >= temphi apply fanmax, - if the temp is within the range, calculate (reading - templo)/(temphi - templo) ------> then check if the pct is outside the fanmin / fanmax and apply this over the top What this does is any temp just over templo will essentially always calculate as a number below fanmin, so instead of a gradient from fanmin to fanmax occuring from templo to temphi you get a flat line of fanmin until the calculation reaches fanmin. To correct this, the code can be adjusted to use fanmin and fanmax to define the range produced and give a nice gradient. In ipmifan change: $pct = ($reading-$templo)/($temphi-$templo); To: $pct = ($reading-$templo)/($temphi-$templo)*($fanmax-$fanmin)/$range + $fanmin/$range; What does this do? I set templo to 30 and temphi to 55 with a fanmin of 51.3. The existing code will apply fanmin from 31 through 42 degrees while the new code will step up from 51.3 % to 61% fan in the same temp range. The below table shows how the existing logic is flatlined on fanmin for ~ half the range vs the proposed logic which will progressively step up fans throughout the range. Temp Existing: Proposed 19 FANMIN FANMIN 20 FANMIN FANMIN 21 FANMIN FANMIN 22 FANMIN FANMIN 23 FANMIN FANMIN 24 FANMIN FANMIN 25 FANMIN FANMIN 26 FANMIN FANMIN 27 FANMIN FANMIN 28 FANMIN FANMIN 29 FANMIN FANMIN 30 FANMIN FANMIN 31 130.815 135.7824 32 130.815 140.7498 33 130.815 145.7172 34 130.815 150.6846 35 130.815 155.652 36 130.815 160.6194 37 130.815 165.5868 38 130.815 170.5542 39 130.815 175.5216 40 130.815 180.489 41 130.815 185.4564 42 130.815 190.4238 43 132.6 195.3912 44 142.8 200.3586 45 153 205.326 46 163.2 210.2934 47 173.4 215.2608 48 183.6 220.2282 49 193.8 225.1956 50 204 230.163 51 214.2 235.1304 52 224.4 240.0978 53 234.6 245.0652 54 244.8 250.0326 55 FANMAX FANMAX 56 FANMAX FANMAX 57 FANMAX FANMAX 58 FANMAX FANMAX 59 FANMAX FANMAX 60 FANMAX FANMAX 61 FANMAX FANMAX 62 FANMAX FANMAX 63 FANMAX FANMAX I'm trialing this code now and it seems to be working nicely. Happy to debate / discuss further . Again I want to reiterate this is an awesome plugin and much appreciated!

I can also confirm working perfectly for me on my x9. Many thanks! Cheers.

Hi dmacias, I am currently away on work travel, however, a mate is setting up an identical server to mine and has kindly tested the x9 update and everything looks to be working properly. Hooray for fan control! I'll have a bit more time at the end of the week to take a closer look but so far all looks good. Thanks!

Believe it or not you were half way there on page 9 in April 2016 - you have a post with a mix of x10/11 and x9 raw commands you asked people to test. which includes the x9 raw strings. You must have found a relevant resource back then. I only found the raw commands after a long and protracted search hidden in the depths of a supermicro FAQ post in response to a query a user raised on another x9 board. It wasn't obvious. I have also noted that ipmi_helpers.php will also need to be updated as it saves the config set by the user assuming 64 steps as well. I have not spent much time tweaking as I am hoping this is a heck of a lot easier for you to update than for me to continue modding. Much appreciated - this is a really great looking plugin for my use case (and obviously for a heck of a lot of other people out there too).

Hi there, I've established manual control of an X9 supermicro boards fans similar to what has been done here for the x10 / x11. The X9 uses a different raw command to set the two zones and has 255 levels vs the 64 levels of the x10 / x11, beyond this its essentially the same. I went in and abused ipmi_settings_fan.php to record my boards raw command, and then went and abused ipmifan to reference the 255 steps and the corrected zone references and on the first crack it is now trying to set the fans... however I have clearly hit something wrong as it is setting the fans to a speed lower than the minimum value. The point of this is it looks quite simple to add support for the supermicro x9 (or at least for my board - X9DRi-LN4+ which reports as a X9DRi-LN4+/X9DR3-LN4+) This is the change to ipmi_settings_fan. The key things to note: The raw command is totally different to the X10/x11 The zones are numbered 10 and 11, not 0 and 1 There are 255 steps (not that this file references step numbers) $board_json = [ 'Supermicro' => [ 'raw' => '00 30 91 5A 3', 'auto' => '00 30 45 01', 'full' => '00 30 45 01 01', 'fans' => [ 'FAN1234' => '10', 'FANA' => '11' ] For those wanting to try on command line, here are some samples i've tested: Set FANA.. fans to ~50% pwm: ipmitool raw 0x30 0x91 0x5A 0x3 0x11 0x80 set FAN1234... fans to ~75% pwm: ipmitool raw 0x30 0x91 0x5A 0x3 0x10 0xBF There is a a few things to change ipmifan. updating the values of 64 to 255 to reflect the PWM steps modding the pwm calc to reference the 255 steps updating the references of the zones to 10 and 11 Initial testing shows that something goes wrong in the determination of the minimal fan threshold, I suspect some other place is again assuming 64 steps in defining the minimum as setting a 60% minimum via the gui is still giving a 25% result - however - it is absolutely controlling fan speed by zone on my board so the principle is proved. Would be really great to add support for this into the plugin - I suspect a lot easier knowing the end to end of it vs reverse engineering any further I am thinking that for supermicro it could be as simple as the gui requiring a user to select x10/11 vs x9 and having this third category supported. Any interest in supporting this?