On Thu, 6 Dec 2007, Brad Nicholes wrote:
> >>> On 12/6/2007 at 5:22 PM, in message
> <[EMAIL PROTECTED]>, Matthias
> Blankenhaus <[EMAIL PROTECTED]> wrote:
>
> >
> > On Thu, 6 Dec 2007, Brad Nicholes wrote:
> >
> >> >>> On Wed, Dec 5, 2007 at 3:48 PM, in message
> >> <[EMAIL PROTECTED]>, Matthias
> >> Blankenhaus <[EMAIL PROTECTED]> wrote:
> >> > Hi Brad !
> >> >
> >> > Nice meeting you yesterday :-)
> >> >
> >> > I took a closer look at PCP to see what it uses for the meta level
> >> > description for every metric. I thought this might be interesting for
> >> > you. Here you go:
> >> >
> >> >
> >> > - Data type: union of all C types, plus blob
> >> > - Semantics: counter, instant, descrete
> >> > - Units and scale: dimension and scale for space, time, count
> >> >
> >> >
> >> > Here are some examples:
> >> >
> >> >
> >> > kernel.all.load [1, 5 and 15 minute load average]
> >> > Data Type: float InDom: 60.2 0xf000002
> >> > Semantics: instant Units: none
> >> >
> >> > kernel.percpu.cpu.user [percpu user CPU time metric from /proc/stat]
> >> > Data Type: 64-bit unsigned int InDom: 60.0 0xf000000
> >> > Semantics: counter Units: millisec
> >> >
> >> >
> >> > For detailed info you can check out "man PMAPI" on any SLES box.
> >> >
> >> >
> >> > Matthias
> >>
> >> If I am understanding this correctly, this is actually similar in concept
> >> to
> > the XDR restructuring that I did for gmond. However the metadata and the
> > value message are split into two different structures. The metadata is a
> > struct that contains the basic metric description elements plus a blob
> > (basically. It is really an array of additional elements). The value
> > message
> > is a union of all of the supported data types. Both message types
> > (metadata,
> > value) carry a metric ID header struct that defines the host, metric name
> > and
> > spoof indicator. Since this structure is basically the header for every
> > XDR
> > message, even before the XDR message type is determined, the host and
> > metric
> > can be identified. Take a look at lib/protocol.h.
> >
> > Among other thinks I saw this:
> >
> > enum Ganglia_value_types {
> > GANGLIA_VALUE_UNKNOWN = 0,
> > GANGLIA_VALUE_STRING = 1,
> > GANGLIA_VALUE_UNSIGNED_SHORT = 2,
> > GANGLIA_VALUE_SHORT = 3,
> > GANGLIA_VALUE_UNSIGNED_INT = 4,
> > GANGLIA_VALUE_INT = 5,
> > GANGLIA_VALUE_FLOAT = 6,
> > GANGLIA_VALUE_DOUBLE = 7,
> > };
> >
> > What does int, short amount to for various platforms ? I think to
> > make this portable you might want to make it explicit to avoid any
> > integral promotion problem, e.g. have INT32, UINT32, INT64, UINT64 types.
> >
> > But maybe, I misunderstood the concept.
> >
> >
>
> True, I guess I am assuming that XDR would take care of that
> (http://en.wikipedia.org/wiki/External_Data_Representation). The point of
> using XDR is to allow the data packets to be transmitted across different
> platforms. So far in my testing I have been exchanging packets between 64
> and 32 bit machines without any problem. If I am assuming too much, then yes
> the data types will have to be more granular. Of course we are also limited
> by the data types that XDR allows you to use when describing a packet.
>
Makes sense ! From RFC1014 it looks like XDR provides four integer type:
[unsigned] integer : 32 bit
[unsigned] hyper integer: 64 bit
Matthias
> Brad
>
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
