perfSONAR User Q&A and Other Discussion

[Brian Candler <>]

On 18/05/2017 18:18, Mark Feit wrote:

(This one will be shorter, I promise.)   (But not by much, apparently.)

:-)

OK, I'm sold on the idea of better queuing of results via postgres.  It means I'd be happier to throw up a shared esmond instance (in a VM say), and have test endpoints without local measurement archives.  Dropping esmond from those nodes would more than compensate for adding postgres.

Regarding the terminology of "lead participant": how does this work for third party tests? For example, http://fasterdata.es.net/performance-testing/network-troubleshooting-tools/pscheduler shows this example:

pscheduler task throughput --source send_host --dest receive_host --duration PT30S

Is the "lead participant" the send_host, or the host which runs the "pscheduler task" request? If the latter, then this test obviously has three participants.

Now, there's one other thing which follows on from this centralisation thought, and it's about mesh configuration.

In perfsonar 3.x, I don't think it was possible to schedule a third-party test via the toolkit GUI (e.g. ask node A to schedule a test from node B to node C), even though bwctl supported this.  So if you wanted a centrally managed set of tests, what you did was to create and publish a mesh config, and get all the nodes to periodically download it, and they would each filter it down to what was pertinent to themselves and run those tests.

I wonder if the new architecture allows a different way of working: could you have a central node which talks directly to all the pschedulers and registers test schedules with them?  Then you could have a central GUI where you could add a test from any X to Y, alongside a single measurement archive which contains all the results.

Regards,

Brian.