RFC: calculating RPM from PWM for fan monitor

[Patrick Venture]

To reach a desired RPM, via PWM, we use a PID+FF algorithm that tries
to reduce the error between the current fan RPM and the set-point RPM
for the fan.  This is in our presently internal implementation of the
fan control for openbmc.  We're still working out how to open
source/upstream it, when there'll now be multiple implementations of
fan controls, etc.

Patrick

On Tue, Jan 23, 2018 at 6:42 AM, Alexander Amelkin <a.amelkin at yadro.com> wrote:
> Lei,
>
> I'm quite new to openbmc and do not yet fully understand its internal
> mechanics, but from my previous experience with other BMC software and
> hardware, I can say that every fan has it's own characteristics that include
> the minimum and maximum RPM it is able to react to and some not necessarily
> linear function between those points.
>
> As far as I remember, AST2500 is able to detect quite any RPM, no matter how
> low it is.
> However, some fans just stop if PWM falls below some threshold and rotate at
> max RPM beyond some max PWM which may be quite less than from 100% (255).
> I've seen Delta's fans that take about 70% PWM as a maximum and fully stop
> below like 20%.
>
> Hence, assuming a single linear slope from 0% to 100% pwm is a bad idea.
>
> Thus, IMO, the yaml file should define a piecewise linear function, and
> maybe jitter level to allow for RPM deviations.
> I would also add a delay after detection of a changed pwm before rpm is
> checked to allow for acceleration/deceleration. From my experience large
> fans (like 100mm) may take up to 4 seconds to reach max rpm from full stop
> condition. This should be taken in account to avoid false alarms.
>
> Alexander Amelkin,
> Leading BMC Firmware Engineer
> YADRO
>
>
> 23.01.2018 12:37, Lei YU wrote:
>>
>> phospohr-fan-monitor compares fan speed with target and determine if the
>> fan
>> is functional:
>>
>> https://github.com/openbmc/phosphor-fan-presence/blob/master/monitor/fan.cpp#L182-L185
>>
>> However, for systems using pwm as target, the logic does not work, because
>> the
>> fan speed is RPM but the target the PWM.
>>
>> So we probably need to have a conversion from PWM target to fan speed RPM.
>>
>> On Romulus, the observation is:
>>
>> | PWM | RPM  |
>> | --- | ---- |
>> | 64  | 3000 |
>> | 96  | 3700 |
>> | 128 | 4300 |
>> | 160 | 4900 |
>> | 192 | 5600 |
>> | 224 | 6300 |
>> | 255 | 7000 |
>>
>> And the linear fit becomes [RPM = 20.7147 * PWM + 1660.04][1]
>>
>> So how do we make fan-monitor to support this?
>>
>> My proposal is to define the parameters, e.g. slope, intercept in the
>> config
>> yaml, and add this support in phosphor-fan-monitor.
>> E.g.
>>      sensors:
>>        - name: fan0
>>          has_target: true
>>          slope: 21
>> intercept: 1600
>>
>> If the yaml config does not define slope/intercept, then the default value
>> is set to 1 and 0 which matches the fan speed target.
>>
>> My question (and concern) is, the fan RPM can not be queried correctly
>> when
>> PWM is set to a low value, e.g. 32, and it means the fit function may not
>> be
>> linear fit.
>>
>> What do you think?
>>
>> [1]:
>> http://m.wolframalpha.com/input/?i=linear+fit+%7B64%2C+3000%7D%2C%7B96%2C+3700%7D%2C%7B128%2C+4300%7D%2C%7B160%2C+4900%7D%2C%7B192%2C+5600%7D%2C%7B224%2C6300%7D%2C%7B255%2C7000%7D
>
>