perfsonar development work

[Nicolas Simar <>]

does those document correspond to a final decision (At least for the 
time being) or do we need to sprcify it properly within the project in a 
document (wiki or SVN page)?

Cheers,
Nicolas

Jeff W. Boote wrote:
> Roman Lapacz wrote:
>
> > Nicolas Simar wrote:
> >
> > > Hi,
> > >
> > > In the RRD MA configuration file, the person who build the metadata 
> > > configuration file  can chose the "Data storage unit".
> > >
> > > The visualisation tools querry the information from the MA.
> > >
> > > What happens if one RRD MA instance export bps, another one kBps?
> > > 1) Do the visualisation tool have to deal with it?
> > > 2) Do the MA have to normalise it?
> > > 3) Are there best practices we should suggest to ensure consistency 
> > > in the service offered globally?
> >
> >
> >
> > I think we should have one terminology for units to avoid the 
> > situation when the same unit will be called differently in two 
> > instances of RRD MA (example bps and bit/s).
>
>
> I agree. See that attached message for suggestions on where we come up 
> with unit names from. (From the last time this topic came up.)
>
> > Transformation between units should be done by transformation service 
> > (TrS). No need to add this functionality to MA (it 's possible but may 
> > increase the time of responses from MA).
>
>
> As I mentioned in my other message. The other possibility is to have the 
> client do it.
>
> jeff
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [pS-dev] [Fwd: units expected from RRD MA]
> From:
> "Jeff W. Boote" 
> <>
> Date:
> Fri, 11 Aug 2006 10:16:42 -0600
> To:
> Vedrin Jeliazkov 
> <>
>
> To:
> Vedrin Jeliazkov 
> <>
> CC:
> Loukik Kudarimoti <>, Roman Lapacz 
> <>, 
>
>
> Vedrin Jeliazkov wrote:
>
> > Hi,
> >
> > Nina and myself agree that:
> >
> > - 'unit' is too generic and calling it <*>valueUnit (as suggested by 
> > Jeff)
> > would be better;
> >
> > - it's preferrable to have <*>valueUnit in datum (as suggested by 
> > Loukik),
> > rather than in metadata;
>
>
> That is fine. It just seems wasteful to repeat a field like that in 
> every single datum when it is common across the full set of data. As I 
> said before, I don't feel strongly about it.
>
> > We also feel that opening the door for free text content of 
> > <*>valueUnit could
> > quickly lead to a multitude of variants for a given unit name in 
> > different
> > service instances. It would be much better if the allowed units are well
> > defined, known by clients and enforced by respective services in some 
> > way. We
> > would very much like to avoid the possibility to have simultaneously:
> >
> > b/s
> > bit/sec
> > bits/sec
> > bits per second
> > etc...
>
>
> I agree. For many of the units there are ISO (or at least SI) standards 
> in place. (For time units for example.) We should use them when we can. 
> And for the others we should make very sure that we have looked. One 
> good place to start is:
>
> http://en.wikipedia.org/wiki/SI
> http://en.wikipedia.org/wiki/Binary_prefix
>
> And, as much as we might think it is confusing. The most common 
> specification of bytes vs bits out there is B vs b. We should stay 
> consistent with the rest of the world here.
>
> > And last, but not least, maybe it would be better to have bytes per 
> > second
> > (instead of bits per second) in the default rrd-database_TEST.xml, 
> > because
> > data sources reporting bytes seem to be more common.
>
>
> We should stay consistent with the default units of the SNMP mib value - 
> which I believe is octets (bytes) in this case.
>
> In general, I don't think we should do units conversion unless it is 
> somehow requested. (Laziness is a virtue in programming. ;) )
>
> jeff

--
Nicolas
______________________________________________________________________

Nicolas Simar
Network Engineer

DANTE - www.dante.net

Tel - BE: +32 (0) 4 366 93 49
Tel - UK: +44 (0)1223 371 300
Mobile: +44 (0) 7740 176 883

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________