perfSONAR User Q&A and Other Discussion

[Philippe Laurens <>]

Hi Mark,

I would also be interested in some bootstrapping help
like a workshop or some annotated example or tutorial.

My first application will be "unconventional".
Besides our AGLT2 center, we also build circuit boards for
the CERN Atlas experiment.  Our current card is an ATCA hub
with a 17 port 1G switch.  I have already found ultra small
factor Dell desktop PCs, very cheap from our campus surplus store.
I have tested one with the toolkit and it seems to work fine
(psmsu03.aglt2.org).

I would like to use pefsonar to characterize one of our cards
by pushing it to its limits in various ways.  Then we will need
some kind of automated acceptance test which can start various
owamp and bandwidth tests and keep logs of the results for each
production card, all programmatically. Python or C/C++ or bash
would be easier choices for me.

However, and unfortunately, I will not be available before Aug 21st.

Thanks,

Philippe


On 8/4/17 3:41 PM, Cong Wang wrote:
> Hi Mark, Dan,
>
> Thank you very much for the insights. It’s great to have the REST APIs for 
> perfSonar 4.0. Can we please do a workshop? That would be super helpful.
>
> Best regards,
> Cong
>
> > On Aug 4, 2017, at 1:54 PM, Mark Feit 
> > <>
> >  wrote:
> >
> > Cong Wang writes:
> >
> >    We are trying to build a platform to collect perfSonar measurement data 
> > from multiple sites in real time. Is there a way to programmatically retrieve 
> > the data from the perfSonar web interface, e.g., through RESTful API? We plan 
> > to collect throughput, latency and packet loss if it works.
> >
> > To expand a bit on what Dan said:
> >
> > All test activity in perfSONAR 4.0 is coordinated by pScheduler, which, as 
> > Dan mentioned, has a REST API for creating measurement tasks and retrieving 
> > the results.  It’s stable but not officially documented.  You’re the first 
> > person outside the project to ask about it, which will probably light a fire 
> > under me to get it done.  All data is JSON and is easy to deal with.  If you 
> > want to do ad hoc measurements, where your platform tells pScheduler to do a 
> > measurement on demand, this is the way to go.  The same API can be used to 
> > start repeating tasks, and by keeping the URL it returns, you can find and 
> > retrieve the results.  If you (or anyone else) is interested, I could do a 
> > brief, informal workshop to go over it and supply some snippets of Python 
> > code that can help get you started.
> >
> > One of the other new features pScheduler brought with it is a system of 
> > plugins that allows us to have multiple ways to dispose of measurement 
> > results.  This would mean you don’t have to retrieve the results yourself; 
> > pScheduler can be directed to send them directly to you and retry if it 
> > fails.  4.0 shipped with plugins that can post results to an HTTP server, 
> > RabbitMQ, the system log or Esmond, which should give you enough options that 
> > developing something custom won’t be necessary.  Information on how to use 
> > archivers with pScheduler can be found here:  
> > https://github.com/perfsonar/pscheduler/wiki/Archivers.
> >
> > The one limitation is that meshconfig can’t be used to configure measurements 
> > that use any archiver other than Esmond.  This is a holdover from earlier 
> > versions of perfSONAR, and we’re working on ways to expose pScheduler’s 
> > additional features to meshconfig.  You can still use the API to run your own 
> > tests in parallel, though.
> >
> > --Mark