perfsonar development work

[Roman Lapacz <>]

Jason Zurawski wrote:
> Jeff & All;
>
> So I guess we took the long way to get to:
>
>  - Throughput is good for iperf
>  - Value is good for most current things; we also shouldn't do a lot 
> of messing with existing things if they aren't broke
>  - sometimes value isn't good, and we should use a different name in 
> those cases
>
> Does that summarize it? :)
>
> Throughput is fine, other than pS-UI and our CGI scripts I can't think 
> of other APIs/clients that would ask for a 'value' from pSB so 
> removing value is fine by me.

To me the current schema for iperf:datum element is fine 
(http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/schema/rnc/iperf.rnc). 
The only open question I see refers to the units fields. Do we want to 
have them or not? I don't have strong opinion (when we have the final 
decision here I will be able to complete my work on the SQL MA with 
iperf stuff so the sooner the better :) but I think it might be useful 
to include them (see my previous email).

Roman


> -jason
>
>
> > On Feb 9, 2009, at 5:26 AM, Jason Zurawski wrote:
> >
> > > Roman Lapacz wrote:
> > > > Jeff W. Boote wrote:
> > > > > From reading Jason's email, I think that I was perhaps not clear.
> > > > >
> > > > > I favor only having 'throughput' - I think 'value' is confusing 
> > > > > for tools that provide multiple types of values.
> > > > >
> > > > > The question for me is one of backward compatibility. If there are 
> > > > > clients out there that expect to see the throughput in a 'value' 
> > > > > attribute, I think we should provide it that way in this version 
> > > > > but deprecate it. And also provide the exact same data in a 
> > > > > throughput attribute so that clients can move to the new method.
> > > > >
> > > > > If we don't have clients to worry about here - then I think we 
> > > > > should immediately drop 'value'.
> > > > I agree. Previously I stated that 'value' is fine for me because I 
> > > > thought it's important for backward compatibility. If it's not we 
> > > > should remove it.
> > > > So the question is: which client app needs 'value' field? Verena, 
> > > > Do you know how is it in pSUI? Jason and Jeff, do you have other 
> > > > client app depending on this?
> > >
> > >
> > > Our cgi scripts are easy enough to change.
> > >
> > > I am still uneasy about this entire conversation because I don't 
> > > believe that we are representing the best interests of other 
> > > services.  Martin had pointed out in previous conversations that it 
> > > is desirable to maintain the time/value pair for simplicity in 
> > > service and API design (Jeff alluded to this as well below).  No 
> > > matter what 'type' of service is being queried, the resulting datum 
> > > should deliver these two attributes.  I agree with this idea 
> > > conditionally, namely because tools such as iperf may have several 
> > > candidates for 'value' and this complicates the choice by the author 
> > > and the expected value to the user.
> >
> > There are several schema's that do not have 'value' in them currently.
> >
> > > If we do eliminate 'value' from this schema, there may be other 
> > > services/schemata that could be re-evaluated to eliminate a generic 
> > > term such as 'value' in place of more descriptive items such as 
> > > 'latency', 'throughput', or 'delay'.  This is too slippery of a 
> > > slope in my opinion, so allowing a questionable tool like iperf a 
> > > pass on this issue doesn't seem reasonable.
> >
> > The slippery slope can be applied the other direction as well... Do 
> > we now have to go through the existing schemata and look for ones 
> > that do NOT use value?
> >
> > I personally think that most tools provide more than one piece of 
> > information, and often it is dependent upon context what the 
> > 'interesting' information you want.
> >
> > I do think value makes sense for things in the 'metric' namespace, 
> > but I'm not convinced it should be required for eventTypes in the 
> > 'tool' namespace.
> >
> > > Half of my $.02 after thinking about this is that 'value' should 
> > > probably stay, if we want compatibility this means that it should 
> > > ride alongside 'throughput' for future releases with a sunset date 
> > > for when 'throughput' stops being supported.  This will complicate 
> > > APIs for the very short term, but eventually we can go back to a 
> > > time/value expected behavior.  The other half of my $.02 is that 
> > > trying to quickly decide the fate of this issue isn't a good idea.  
> > > I know our face to face meetings are getting further and further 
> > > apart, but discussing this in a wider forum may help.
> >
> > I think perfsonar-dev is a wide enough forum (and likely wider than 
> > any f2f we could have) to decide.
> >
> > If anyone is currently using 'value', than lets keep it along with 
> > throughput. If not, then this is a non-issue.
> >
> > jeff
> >
> > > -jason
> > >
> > >
> > > > Roman
> > > > > jeff
> > > > >
> > > > > On Feb 6, 2009, at 9:52 AM, Jason Zurawski wrote:
> > > > >
> > > > > > All;
> > > > > >
> > > > > > In the end I dont have a strong opinion either way. Just note 
> > > > > > that we do have many legacy pSBs on Knoppix disks that will 
> > > > > > always report 'throughput'. If we want future versions to report 
> > > > > > 'value', 'throughput', or even both I can do that, but for 
> > > > > > Roman's sake he may need to recognize both for the foreseeable 
> > > > > > future.
> > > > > >
> > > > > > If we want to be consistent with other tools I suppose sticking 
> > > > > > with value is appropriate, but I feel its less descriptive for 
> > > > > > something like iperf that does report several 'values' for 
> > > > > > output. I am sure there are more tools out there in the same 
> > > > > > boat, so sticking with the value paradigm just because 
> > > > > > 'everything else does it' doesn't completely convince me.
> > > > > >
> > > > > > -jason
> > > > > >
> > > > > >
> > > > > > > I don't think it is such a good idea to keep both value and 
> > > > > > > throughput. This complicates clients since they will not know 
> > > > > > > which one a particular service will use. I can see doing this as 
> > > > > > > part of a well defined transition plan - for example this 
> > > > > > > version of the service MUST specify both so that old clients are 
> > > > > > > not broken, and value is expected to be removed in the next 
> > > > > > > major release.
> > > > > > > Just letting service use which ever one they want is not nice 
> > > > > > > for clients. (Or am I mis-understanding?)
> > > > > > > jeff
> > > > > > > On Feb 6, 2009, at 6:39 AM, Roman Lapacz wrote:
> > > > > > > > Verena Venus wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > Am Friday 06 February 2009 14:23:24 schrieb Roman Lapacz:
> > > > > > > > >
> > > > > > > > > > Jason Zurawski wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Jason,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > The schema does not have 'throughput' or 'jitter' elements.
> > > > > > > > > > > Corrected in my doc and the iperf schema in the main pS 
> > > > > > > > > > > repo. Jitter
> > > > > > > > > > > *should* have been there since this is reported by iperf UDP 
> > > > > > > > > > > tests.
> > > > > > > > > > >
> > > > > > > > > > > Throughput is more descriptive than 'value' in my opinion 
> > > > > > > > > > > (since there
> > > > > > > > > > > are many 'values' that can be returned by an iperf test). I 
> > > > > > > > > > > have
> > > > > > > > > > > added throughput to the schema but kept value for now in 
> > > > > > > > > > > case VV or
> > > > > > > > > > > anyone else has a use for it.
> > > > > > > > > > >
> > > > > > > > > > > I think we should talk about deprecating the attribute or 
> > > > > > > > > > > perhaps
> > > > > > > > > > > allowing it to stay with a use that will vary by service (I 
> > > > > > > > > > > would
> > > > > > > > > > > prefer the latter).
> > > > > > > > > > The latter is fine for me as well.
> > > > > > > > > >
> > > > > > > > > > I've just created RC1 of Java SQL MA v.2.1.1 with iperf stuff 
> > > > > > > > > > and
> > > > > > > > > > previous schema. On Monday I will create the new one (RC2) 
> > > > > > > > > > with your
> > > > > > > > > > updates (compatibility has hight priority!).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Verena, any comments on changes?
> > > > > > > > > It would be nice, if you could send me the new 
> > > > > > > > > schemata/examples when everything is settled. I can do the 
> > > > > > > > > changes then very quickly.
> > > > > > > >
> > > > > > > > I will updated the service and message examples and send them 
> > > > > > > > to you on Monday.
> > > > > > > >
> > > > > > > > Roman