Discussion:
Floating values
Asim Zaka
2005-11-09 06:58:46 UTC
Permalink
Hi,

What data type should I use in MIB definition and in the var_ function if I want
to return negative decimal values like -1.2?

Regards,
Asim Pervez Zaka.
Dave Shield
2005-11-09 08:09:23 UTC
Permalink
Post by Asim Zaka
What data type should I use in MIB definition and in the var_ function if I want
to return negative decimal values like -1.2?
There is no standard support for non-integer numeric values in SNMP.
You have three basic choices:

- for fixed-point values, use an integer value with an implicit
decimal point. For example, TimeTicks would represent 1.2s
using the value 120.

- the Net-SNMP suite supports the type NET-SNMP-TC::Float (and
Double), as used in UCD-SNMP-MIB::laLoadFloat.
But this will typically only work with Net-SNMP agent and tools.
Very few other SNMP toolkits understand this type.

- use a printable string - e.g. "-1.2" and parse this at the
receiving end.

Dave
Asim Zaka
2005-11-09 12:56:08 UTC
Permalink
Hi Amber and Dave,

My snmp agent uses net-snmp's read function var_xyz and returns temperature
readings to the remote snmp manager. The values can be from a range of -200 to
+ 300 depending on the sensors being used. a typical value could be "-1.2"
degree celcius.

- What I working on is converting the float value into a string and returning it
in the unsigned char* buffer as OCTET String. I would have to change the MIB
variable type to OCTET-STRING both at the manager and the agent side, right?

thanks for the time and help.

Asim.
Post by Dave Shield
Post by Asim Zaka
What data type should I use in MIB definition and in the var_ function if I
want
Post by Asim Zaka
to return negative decimal values like -1.2?
There is no standard support for non-integer numeric values in SNMP.
- for fixed-point values, use an integer value with an implicit
decimal point. For example, TimeTicks would represent 1.2s
using the value 120.
- the Net-SNMP suite supports the type NET-SNMP-TC::Float (and
Double), as used in UCD-SNMP-MIB::laLoadFloat.
But this will typically only work with Net-SNMP agent and tools.
Very few other SNMP toolkits understand this type.
- use a printable string - e.g. "-1.2" and parse this at the
receiving end.
Dave
Regards,
Asim Pervez Zaka.
Dave Shield
2005-11-09 13:56:38 UTC
Permalink
Post by Asim Zaka
My snmp agent uses net-snmp's read function var_xyz and returns temperature
readings to the remote snmp manager. The values can be from a range of -200 to
+ 300 depending on the sensors being used. a typical value could be "-1.2"
degree celcius.
What degree of accuracy does your sensor work to?
If this only needs one decimal place, then you could use a (signed)
INTEGER value, running from -2000 to +3000
Your typical value would then be reported as -12

Two decimal places could be handled using a range -20000 to +30000
(with your typical value being reported as -120). This could
be used for anything up to six decimal places, within the 32-bit
limits of SNMP integers.

The MIB syntax is capable of representing this quite happily.
But you would need to choose the level of accuracy to work with
in advance, and stick to it.
Post by Asim Zaka
- What I working on is converting the float value into a string and
returning it in the unsigned char* buffer as OCTET String.
That would certainly work, yes.
Post by Asim Zaka
I would have to change the MIB variable type to OCTET-STRING both
at the manager and the agent side, right?
Correct.
The two sides must work with the same MIB definitions.
Otherwise they're going to get hopelessly confused!

Dave
Robert Story
2005-11-09 15:54:48 UTC
Permalink
On Wed, 09 Nov 2005 15:52:57 +0000 Dave wrote:
DS> > I would have to change the MIB variable type to OCTET-STRING both
DS> > at the manager and the agent side, right?
DS>
DS> Correct.
DS> The two sides must work with the same MIB definitions.
DS> Otherwise they're going to get hopelessly confused!

Also note that if you've shipped devices with the old MIB, or given the old
MIB to customers w/out the understanding that it wasn't finalized, you really
really shouldn't be changing object types. Instead, deprecated the old object,
and add a new one.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.

Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>

You are lost in a twisty maze of little standards, all different.
David T. Perkins
2005-11-09 20:39:46 UTC
Permalink
HI

I tried many years ago to add floating point as a base type to
the SNMP protocol. However, this was not successful.

If you really need a floating point type, then best choice
is to use a displayable string representation (which
uses OCTET STRING for the base type). I would suggest that
you define a textual convention that describes the values
for the pointing float including plus and negative infinity,
and "not a number".

With this approach, you should be able to retrieve (and modify)
floating point numbers from/to SNMP agents. However, existing
management apps will not know that the values are floating
point and treat the values as strings. But you can still create
custom management apps that understanding the values, and
you should also be able to export/import the values into other
programs (such as spread sheet apps like Excel), and
manipulate the values.

Regards,
/david t. perkins
Post by Dave Shield
Post by Asim Zaka
My snmp agent uses net-snmp's read function var_xyz and returns temperature
readings to the remote snmp manager. The values can be from a range of -200 to
+ 300 depending on the sensors being used. a typical value could be "-1.2"
degree celcius.
What degree of accuracy does your sensor work to?
If this only needs one decimal place, then you could use a (signed)
INTEGER value, running from -2000 to +3000
Your typical value would then be reported as -12
Two decimal places could be handled using a range -20000 to +30000
(with your typical value being reported as -120). This could
be used for anything up to six decimal places, within the 32-bit
limits of SNMP integers.
The MIB syntax is capable of representing this quite happily.
But you would need to choose the level of accuracy to work with
in advance, and stick to it.
Post by Asim Zaka
- What I working on is converting the float value into a string and
returning it in the unsigned char* buffer as OCTET String.
That would certainly work, yes.
Post by Asim Zaka
I would have to change the MIB variable type to OCTET-STRING both
at the manager and the agent side, right?
Correct.
The two sides must work with the same MIB definitions.
Otherwise they're going to get hopelessly confused!
Dave
-------------------------------------------------------
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Net-snmp-coders mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Darren Gamble
2005-11-09 21:09:38 UTC
Permalink
Post by David T. Perkins
HI
I tried many years ago to add floating point as a base type to
the SNMP protocol. However, this was not successful.
If you really need a floating point type, then best choice
is to use a displayable string representation (which
uses OCTET STRING for the base type). I would suggest that
you define a textual convention that describes the values
for the pointing float including plus and negative infinity,
and "not a number".
Just to add to this, there are a number of "standard" OIDs that do use
this method to represent floating point numbers; there is are load
average objects in the host MIB that comes to mind (there are also other
values that store an integer which contains the load average times 100,
as per one of the other suggestions given here).

Many management applications can natively handle these string objects as
numbers. I know Cacti does, for example. In your case with
temperatures, either of these methods could work.

FYI,

============================
Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948
Dave Shield
2005-11-10 07:05:10 UTC
Permalink
Post by Darren Gamble
Just to add to this, there are a number of "standard" OIDs that do use
this method to represent floating point numbers; there is are load
average objects in the host MIB that comes to mind
Talking about "the host MIB" is somewhat misleading.
My immediate reaction was that you were referring to the
Host Resources MIB, where the processor load object
(hrProcessorLoad) is actually a percentage value - an
unsigned integer.
Post by Darren Gamble
(there are also other values
that store an integer which contains the load average
times 100, as per one of the other suggestions given here).
I believe that you are actually referring to the load
average table in the UCD-SNMP-MIB - yes? In fact, that
table illustrates all three approaches I described yesterday:

- an integer representing a fixed-point value
(laLoadInt)
- an opaque-wrapped floating point value
(laLoadFloat)
- a printable string representation
(laLoad)

These three objects all report exactly the same underlying
value, but in three different forms.


Dave
a***@wipro.com
2005-11-10 02:49:29 UTC
Permalink
Hi Asim,
If you are using OCTECT String to represent float values, your mib
should have this object defined as OCTECT String. Aren't you using same
MIB at both Manager and Agent side? You can use displayString also by
importing it from RFC1213 in your mib. Any restrictions in using
displayStrings?

Amber

-----Original Message-----
From: Asim Zaka [mailto:***@violasystems.com]
Sent: Wednesday, November 09, 2005 8:22 PM
To: Dave Shield; Amber Gupta (WT01 - Voice & Next Generation Networks)
Cc: net-snmp-***@lists.sourceforge.net
Subject: Re: Floating values


Hi Amber and Dave,

My snmp agent uses net-snmp's read function var_xyz and returns
temperature
readings to the remote snmp manager. The values can be from a range of
-200 to
+ 300 depending on the sensors being used. a typical value could be
"-1.2"
degree celcius.

- What I working on is converting the float value into a string and
returning it
in the unsigned char* buffer as OCTET String. I would have to change the
MIB
variable type to OCTET-STRING both at the manager and the agent side,
right?

thanks for the time and help.

Asim.
Post by Dave Shield
Post by Asim Zaka
What data type should I use in MIB definition and in the var_
function if I
Post by Dave Shield
want
Post by Asim Zaka
to return negative decimal values like -1.2?
There is no standard support for non-integer numeric values in SNMP.
- for fixed-point values, use an integer value with an implicit
decimal point. For example, TimeTicks would represent 1.2s
using the value 120.
- the Net-SNMP suite supports the type NET-SNMP-TC::Float (and
Double), as used in UCD-SNMP-MIB::laLoadFloat.
But this will typically only work with Net-SNMP agent and tools.
Very few other SNMP toolkits understand this type.
- use a printable string - e.g. "-1.2" and parse this at the
receiving end.
Dave
Regards,
Asim Pervez Zaka.
Darren Gamble
2005-11-10 13:49:40 UTC
Permalink
Good day,
Post by Dave Shield
I believe that you are actually referring to the load
average table in the UCD-SNMP-MIB - yes? In fact, that
Bah, yes, sorry. I had thought that these objects were in the host mib.
Post by Dave Shield
- an integer representing a fixed-point value
(laLoadInt)
- an opaque-wrapped floating point value
(laLoadFloat)
- a printable string representation
(laLoad)
These three objects all report exactly the same underlying
value, but in three different forms.
Yes, I was (not too successfully, it seems) trying to show existing
oids, for reference, that represented the different formats that you
explained.

Thanks for clarifying my statement.

============================
Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948

Loading...