All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Feist <james.feist@linux.intel.com>
To: Patrick Venture <venture@google.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Matt Spinler <mspinler@linux.vnet.ibm.com>,
	Brad Bishop <bradleyb@fuzziesquirrel.com>
Subject: Re: Notion of Flakiness in Sensor Readings
Date: Fri, 12 Oct 2018 14:08:12 -0700	[thread overview]
Message-ID: <3fc8bbb4-2db9-6df0-4fc3-1addf4b94ac3@linux.intel.com> (raw)
In-Reply-To: <CAO=notz_KizBdONsKjtQ6U05r4hWQOuxa_cx9Cshps7V8=PRbw@mail.gmail.com>

On 10/12/2018 01:53 PM, Patrick Venture wrote:
> Currently, there are a few approaches in phosphor-hwmon on how to
> handle sensors being present sometimes, or flaky on reads.  We've
> talked in the past about how to handle a read failure that should be
> ignored.  A real failure that is flaky or temporary.
> 
> I was thinking of just adding a property to the Sensor.Value interface
> to report information.  Basically, someone reading the value needs to
> know if it's valid.  The idea of a range check for validity doesn't
> work as cleanly for this specific purpose, in my opinion.  The min/max
> can be used cleanly to determine the linearization though!
> 
> I was thinking perhaps a boolean, that you can check to see if the
> value should be used or trusted.  Then, I thought, perhaps, a enum
> with a series of states, starting with the states of "Valid',
> "Invalid."  Not being able to think of a third state, I fell back onto
> a boolean.

For Valid / Invalid we've produced nan on D-Bus to know that the sensor 
is in an invalid state (like power off for tach values). Although I'm 
not sure how this would be produced using the int64 interface, for the 
double std::nan will go over d-bus correctly.

> 
> Thoughts?
> 
> Patrick
> 

  reply	other threads:[~2018-10-12 21:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12 20:53 Notion of Flakiness in Sensor Readings Patrick Venture
2018-10-12 21:08 ` James Feist [this message]
2018-10-12 21:23   ` Patrick Venture
2018-10-12 21:28     ` Matt Spinler
2018-10-12 21:32       ` Patrick Venture
2018-10-15 13:39         ` Matthew Barth
2018-10-15 14:34           ` Patrick Venture
2018-10-16  1:14         ` Brad Bishop
2018-10-16  2:15           ` Patrick Venture
2018-10-16  2:30             ` Brad Bishop
2018-10-16  2:34               ` Patrick Venture

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3fc8bbb4-2db9-6df0-4fc3-1addf4b94ac3@linux.intel.com \
    --to=james.feist@linux.intel.com \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=mspinler@linux.vnet.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=venture@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.