RFC: calculating RPM from PWM for fan monitor

[Xo Wang]

I think the parameters that Lei proposed are equivalent to the two
feedforward coefficients we have (a slope for an assumed linear
relationship between a fan's PWM command and its RPM output; and an
offset to account for fan start).

However adding feedforward coefficients isn't the same as detecting
fan malfunction as Lei wants. I think to do that, we have to look at
the feedback part of it and have a parameter that decides "too much
feedback has been required" to hit the target RPM and declare an error
condition.

On Tue, Jan 23, 2018 at 11:02 AM, Patrick Venture <venture at google.com> wrote:
> 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
>>
>>