All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	lm-sensors <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] [PATCH 1/2] Define sysfs interfaces for ibmaem
Date: Mon, 31 Mar 2008 21:01:35 +0000	[thread overview]
Message-ID: <20080331210135.GC7183@tree.beaverton.ibm.com> (raw)
In-Reply-To: <20080329145603.7e47418f@hyperion.delvare>

On Sat, Mar 29, 2008 at 02:56:03PM +0100, Jean Delvare wrote:
> > +energy[1-*]_input		Instantaneous energy use
> 
> This doesn't make sense to me. Energy is a quantity, it exists
> independently of time. An "instantaneous energy use" only makes sense
> if you tell in what (presumably very small) amount of time the energy
> was used... and then what you are measuring is not an energy but a
> power, for which we already have an interface. Please clarify.

Wes Felter suggested "Cumulative energy use", and I'll go with that.

> > +power[1-*]_interval		Power use averaging interval
> 
> Wouldn't power[1-*]_average_interval be clearer?

Given that power is energy used over a period of time, I wonder if it
might be more accurate to remove powerX_input and leave this name alone.
That said, it does seem to be the case that interval names take the
format "${sensorfile}_interval", so I suppose it makes more sense the
way that you suggest.

> > +				Unit: milliseconds
> 
> Nitpicking for consistency: millisecond (no trailing s).
> 
> What values do you expect for this entry? I am wondering if it's safe
> to use millisecond as a unit. Is it unlikely that a future chip will
> support averaging intervals below the millisecond?

It's possible that a future chip could do this, though today we only
support intervals in the hundreds of milliseconds.  The default for the
ibmaem driver is currently 1s.

--D

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	lm-sensors <lm-sensors@lm-sensors.org>
Subject: Re: [PATCH 1/2] Define sysfs interfaces for ibmaem driver
Date: Mon, 31 Mar 2008 14:01:35 -0700	[thread overview]
Message-ID: <20080331210135.GC7183@tree.beaverton.ibm.com> (raw)
In-Reply-To: <20080329145603.7e47418f@hyperion.delvare>

On Sat, Mar 29, 2008 at 02:56:03PM +0100, Jean Delvare wrote:
> > +energy[1-*]_input		Instantaneous energy use
> 
> This doesn't make sense to me. Energy is a quantity, it exists
> independently of time. An "instantaneous energy use" only makes sense
> if you tell in what (presumably very small) amount of time the energy
> was used... and then what you are measuring is not an energy but a
> power, for which we already have an interface. Please clarify.

Wes Felter suggested "Cumulative energy use", and I'll go with that.

> > +power[1-*]_interval		Power use averaging interval
> 
> Wouldn't power[1-*]_average_interval be clearer?

Given that power is energy used over a period of time, I wonder if it
might be more accurate to remove powerX_input and leave this name alone.
That said, it does seem to be the case that interval names take the
format "${sensorfile}_interval", so I suppose it makes more sense the
way that you suggest.

> > +				Unit: milliseconds
> 
> Nitpicking for consistency: millisecond (no trailing s).
> 
> What values do you expect for this entry? I am wondering if it's safe
> to use millisecond as a unit. Is it unlikely that a future chip will
> support averaging intervals below the millisecond?

It's possible that a future chip could do this, though today we only
support intervals in the hundreds of milliseconds.  The default for the
ibmaem driver is currently 1s.

--D

  parent reply	other threads:[~2008-03-31 21:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28 21:36 [lm-sensors] [PATCH 1/2] Define sysfs interfaces for ibmaem driver Darrick J. Wong
2008-03-28 21:36 ` Darrick J. Wong
2008-03-29 13:56 ` [lm-sensors] [PATCH 1/2] Define sysfs interfaces for ibmaem Jean Delvare
2008-03-29 13:56   ` [PATCH 1/2] Define sysfs interfaces for ibmaem driver Jean Delvare
2008-03-31 19:55   ` [lm-sensors] [PATCH 1/2] Define sysfs interfaces for ibmaem Wes Felter
2008-03-31 19:55     ` [PATCH 1/2] Define sysfs interfaces for ibmaem driver Wes Felter
2008-03-31 21:01   ` Darrick J. Wong [this message]
2008-03-31 21:01     ` Darrick J. Wong
2008-04-01  8:22     ` [lm-sensors] [PATCH 1/2] Define sysfs interfaces for ibmaem Jean Delvare
2008-04-01  8:22       ` [PATCH 1/2] Define sysfs interfaces for ibmaem driver Jean Delvare
2008-04-01  8:47       ` [lm-sensors] [PATCH 1/2] Define sysfs interfaces for ibmaem Darrick J. Wong
2008-04-01  8:47         ` [PATCH 1/2] Define sysfs interfaces for ibmaem driver Darrick J. Wong

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=20080331210135.GC7183@tree.beaverton.ibm.com \
    --to=djwong@us.ibm.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mhoffman@lightlink.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.