RFC: calculating RPM from PWM for fan monitor

Lei YU mine260309 at gmail.com
Wed Jan 24 17:50:17 AEDT 2018


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
>>>
>>>


More information about the openbmc mailing list