Skip to contentSkip to conversation

Proposal to change sensor interface to use double values

DISCUSSION James Feist 5 participants 5 messages Aug 6, 2018

lore
Share & tools
lore
#0 lore raw

I've submitted a change to modify the sensor interface to remove scale, and make the sensor value a double. The main reason for doing this is simplification of the interface. In most usages, daemons pull the value, and the scale, then immediately translate this value to a double. This could easily be done once by the sensor producer instead of all daemons. The counter example that was given was phosphor-fan-presence, but doing a quick grep I can't find scale being used, so this might mean for a scaled fan you have to factor that in to all configuration files, or scaled fans aren't supported. The threshold interface is not usable independent from the value interface, as the thresholds are affected by the same scale. Using a fixed scale also won't work well for a logarithmic sensor, while floating point would. Realistic precision should not be affected for any common sensor. We also in the future may be interested in a daemon producing a threshold for a sensor that another daemon owns. With the scale existing elsewhere, this would not be trivial to map.

Review for context: https://gerrit.openbmc-project.xyz/#/c/11739/

This change is not ready to be submitted as is, but we would like to hear if there are any major objections. If not, we would like to start an upgrade path to support both interfaces until it is possible to make the switch. Bmcweb already supports both. In most cases this is just pulling the value using a visitor, and setting the scale to 0 if it does not exist. Max and Min can also be used for IPMI scaling.

Thanks,

- James Feist

#1 lore raw
Quoted 16 lines · James Feist

I've submitted a change to modify the sensor interface to remove scale, and make the sensor value a double. The main reason for doing this is simplification of the interface. In most usages, daemons pull the value, and the scale, then immediately translate this value to a double. This could easily be done once by the sensor producer instead of all daemons. The counter example that was given was phosphor-fan-presence, but doing a quick grep I can't find scale being used, so this might mean for a scaled fan you have to factor that in to all configuration files, or scaled fans aren't supported. The threshold interface is not usable independent from the value interface, as the thresholds are affected by the same scale. Using a fixed scale also won't work well for a logarithmic sensor, while floating point would. Realistic precision should not be affected for any common sensor. We also in the future may be interested in a daemon producing a threshold for a sensor that another daemon owns. With the scale existing elsewhere, this would not be trivial to map.

Quoted 8 lines

Review for context: https://gerrit.openbmc-project.xyz/#/c/11739/

This change is not ready to be submitted as is, but we would like to hear if there are any major objections. If not, we would like to start an upgrade path to support both interfaces until it is possible to make the switch. Bmcweb already supports both. In most cases this is just pulling the value using a visitor, and setting the scale to 0 if it does not exist. Max and Min can also be used for IPMI scaling.

I'm fine with this. It saves everybody converting it to a double before using. Further scaling, which can be necessary can be further done against the double. For instance, with ipmi, to fit a value we sometimes scale again.

Quoted 6 lines

Thanks,

- James Feist

#2 lore raw

Same, I'm ok with this.

Quoted 49 lines · Patrick Venture
Quoted 1 line · James Feist

I've submitted a change to modify the sensor interface to remove scale,

and

Quoted 2 lines

make the sensor value a double. The main reason for doing this is simplification of the interface. In most usages, daemons pull the value,

and

Quoted 3 lines

the scale, then immediately translate this value to a double. This could easily be done once by the sensor producer instead of all daemons. The counter example that was given was phosphor-fan-presence, but doing a

quick

Quoted 1 line

grep I can't find scale being used, so this might mean for a scaled fan

you

Quoted 2 lines

have to factor that in to all configuration files, or scaled fans aren't supported. The threshold interface is not usable independent from the

value

Quoted 1 line

interface, as the thresholds are affected by the same scale. Using a

fixed

Quoted 2 lines

scale also won't work well for a logarithmic sensor, while floating point would. Realistic precision should not be affected for any common sensor.

We

Quoted 1 line

also in the future may be interested in a daemon producing a threshold

for a

Quoted 6 lines

sensor that another daemon owns. With the scale existing elsewhere, this would not be trivial to map.

Review for context: https://gerrit.openbmc-project.xyz/#/c/11739/

This change is not ready to be submitted as is, but we would like to

hear if

Quoted 3 lines

there are any major objections. If not, we would like to start an upgrade path to support both interfaces until it is possible to make the switch. Bmcweb already supports both. In most cases this is just pulling the

value

Quoted 2 lines

using a visitor, and setting the scale to 0 if it does not exist. Max and Min can also be used for IPMI scaling.

I'm fine with this. It saves everybody converting it to a double before using. Further scaling, which can be necessary can be further done against the double. For instance, with ipmi, to fit a value we sometimes scale again.

Quoted 6 lines

Thanks,

- James Feist

#3 lore raw
Quoted 45 lines · Emily Shaffer

Same, I'm ok with this.

Quoted 41 lines · Patrick Venture
Quoted 1 line · James Feist

I've submitted a change to modify the sensor interface to remove scale,

and

Quoted 2 lines

make the sensor value a double. The main reason for doing this is simplification of the interface. In most usages, daemons pull the value,

and

Quoted 3 lines

the scale, then immediately translate this value to a double. This could easily be done once by the sensor producer instead of all daemons. The counter example that was given was phosphor-fan-presence, but doing a

quick

Quoted 1 line

grep I can't find scale being used, so this might mean for a scaled fan

you

Quoted 2 lines

have to factor that in to all configuration files, or scaled fans aren't supported. The threshold interface is not usable independent from the

value

Quoted 1 line

interface, as the thresholds are affected by the same scale. Using a

fixed

Quoted 2 lines

scale also won't work well for a logarithmic sensor, while floating point would. Realistic precision should not be affected for any common sensor.

We

Quoted 1 line

also in the future may be interested in a daemon producing a threshold

for a

Quoted 6 lines

sensor that another daemon owns. With the scale existing elsewhere, this would not be trivial to map.

Review for context: https://gerrit.openbmc-project.xyz/#/c/11739/

This change is not ready to be submitted as is, but we would like to

hear if

Quoted 3 lines

there are any major objections. If not, we would like to start an upgrade path to support both interfaces until it is possible to make the switch. Bmcweb already supports both. In most cases this is just pulling the

value

Quoted 2 lines

using a visitor, and setting the scale to 0 if it does not exist. Max and Min can also be used for IPMI scaling.

I'm fine with this. It saves everybody converting it to a double before using. Further scaling, which can be necessary can be further done against the double. For instance, with ipmi, to fit a value we sometimes scale again.

+2

And for anyone complaining about a loss of precision, keep in mind we are reading low-precision ADCs and stuff like that anyway. The original design may have had a ton of precision (with a 64-bit value and a 64-bit exponent), but it was not being used to the point that demotion to a double will cause a loss of significant figures. This will maintain every bit of precision that was there from the hardware, but in a much more efficient manner.

--Vernon