RFC: calculating RPM from PWM for fan monitor

[Lei YU]

I have submitted this proposal to https://gerrit.openbmc-project.xyz/#/c/8661/

On Wed, Jan 24, 2018 at 2:50 PM, Lei YU <mine260309 at gmail.com> wrote:
> On Wed, Jan 24, 2018 at 9:22 AM, Xo Wang <xow at google.com> wrote:
>> 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).
>
> Thanks Xo for the info!
>
>>
>> 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.
>
> The idea of detecting fan error is simple in the code, which uses a deviation to
> check if the fan speed in in the expected range.
> So if we have defined the slope and the offset for a fan, the monitor is able to
> calculate the expected RPM and check if the fan speed. is out of range,
>
> And this proposal will not impact the current phosphor-fan-monitor too
> much, only
> two new parameters are added.
>
>>
>> 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.
>>>
>
> Thanks Patrick for this info. I guess the community would like to have
> alternatives for
> fan controls. Maybe a new repo like "google-fan-control" for this?
> Anyway it's up to you and the community to decide what is the best :D
>
>>> 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
>>>>
>>>>