perfsonar development work

[Joe Metzger <>]

Nicolas Simar wrote:
> Joe Metzger wrote:
> > Nicolas,
> > I like the direction your headed, but I am not so sure about your
> > initial assumptions.
> >
> > The ESnet SNMP collection system is currently collecting 4622
> > targets when you add up all the traffic, error, discard and qos
> > specific interface counters.  All of these will be rolled into
> > perfSONAR server(s) once AAA is available...
>
> Do you intend to use perfSONAR internally for your monitoring tools?

Yes. The perfSONAR architecture is better than what we have now. So,
I want to move to the perfSONAR tools once they have matured to the
point where they have the capabilities, performance and reliability
I need, (and I have time to convert everything.)

> > Is it reasonable to multiple your numbers by 5?   :-)
>
> So you would rather suggest 360 requests per seconds (Averaged over 5 
> minutes).

Yes. But I expect some of the developers might find this number a bit 
optimistic.

In general the diversity and reliability requirements will require
deploying multiple servers in geographically diverse locations, but
one server should be capable of handling it all in the case of failures
or planned maintenance events.




> It seems that we will have to take one problem at a time and provide 
> some performances vs time/events.
> Something like, we have one client making use of all the data, he is 
> expected to be there by time x, so the performances at that time should 
> be equal to ... A second client is coming by time x, so the performances 
> should be ...
>
> I would add as a question, would a client be capable of coping with all 
> those data?
>
> Cheers,
> Nicolas
>
> > --Joe
> >
> >
> > Nicolas Simar wrote:
> >
> > > Jeff W. Boote wrote:
> > >
> > > > Other:
> > > >   - performance targets (we need to quantify, but it would be good to 
> > >
> > >
> > > During a previous conf call internal to JRA1, we had some thoughts on 
> > > performances parameters (based on TNO feedback).
> > > This is specific for an MA having interface statistics.
> > >
> > > The largest network we have encountered so far is Uninett with 700 
> > > interfaces. So a target of 1000 interfaces is something we should 
> > > achieve.
> >
> >
> > > We could have several metrics per service:
> > > - link utilisation in/out (2)
> > > - interface input errors (1)
> > > - interface drops and per service (BE, LBE, Premium, NC) (4)
> > > That makes 7 values.
> > >
> > > A visualisation tool like a weathermap displaying those data would 
> > > every 5 minutes querry the MA for all those data.
> > > This makes 7000 requests over 5 minutes - 300 secs (Assuming that the 
> > > requests are evenly spread, which is not the case). This means 24 
> > > request per seconds.
> > >
> > > One could think that several tools may be querying simultaneously the 
> > > MA, let's say 3. This would mean 72 requests per seconds.
> > >
> > > We could also assume that before sending those requests, the client 
> > > would want to know all the interfaces and metrics made available by 
> > > the MA: so this means three MetadataKeyRequest every 5 minutes 
> > > (unless it uses the LS for that).
> > >
> > > Those figures are I think long term goals. When a large 
> > > infrastructure would be deployed.
> > >
> > > I don't have any idea on how to estimate the number of request done 
> > > to the LS or to the
> > >
> > > My 2 cents,