RFC: calculating RPM from PWM for fan monitor

[Patrick Venture]

Lei;

The google originated fan control daemon will be posted for review
either once I get it approved as an independent open source
contribution, or preferably once openbmc is given over to the LF.

Patrick

On Fri, Jan 26, 2018 at 1:29 AM, Lei YU <mine260309 at gmail.com> wrote:
> 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
>>>>>
>>>>>