perfsonar development work

["Jeff W. Boote" <>]

On Feb 10, 2009, at 3:35 AM, Roman Lapacz wrote:

> Jeff W. Boote wrote:
> > On Feb 9, 2009, at 5:20 AM, Roman Lapacz wrote:
> > > > You didn't mention loss earlier, but yes this should be there  
> > > > too.  I will add it.
> > >
> > > I just took a look at an example of iperf output :)
> > >
> > > > I have no problem adding the 'units' fields, but lets let  
> > > > everyone weigh in.
> > >
> > > OK. Verena, Jeff what's your opinions on this?
> >
> > I would prefer not specifying units in the schema. I don't see any  
> > reason not to require that the units be something specific when  
> > encoding the data in the schema. But, I'm sure reasonable people  
> > might disagree with me on this one. (For example, when Verena and I  
> > worked on the OWD schema, we decided delays would be in seconds. No  
> > units.)
> >
> > If there is some reason different units are useful, like in the  
> > case with sharing SNMP data, then we should do it. (i.e. lots of  
> > existing data is already collected and there is no clear winner as  
> > to what people are using. We don't want to make 'services'  
> > transform the data unless necessary for performance reasons.) I  
> > don't personally think that is the case here.
>
> Including units fields would be useful for client applications. This  
> way such information wouldn't have to be statically encoded in the  
> clients.

You are either encoding the parameter name that indicates the units,  
or encoding the units directly in the client. There is no free lunch.

Unless we expect the data to be generated in multiple units, and  
expensive to convert to a canonical representation I don't see the  
advantage. My goal here is in simplifying the representation for  
client applications. The fewer permutations of options that they have  
to look at, the better.

jeff