Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] maddash question

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] maddash question


Chronological Thread 
  • From: Brian Candler <>
  • To: "Garnizov, Ivan (RRZE)" <>, Andrew Lake <>
  • Cc: "" <>
  • Subject: Re: [perfsonar-user] maddash question
  • Date: Thu, 10 Sep 2015 15:42:20 +0300
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type; q=dns; s=sasl; b=U1CKJ9YUe2KxQhNZoY0lyxJ5JIQ/jTe0 mgV7kpqJC3ubPieVwo09IoLgAwRfyK2vBLqeiyDqrZVmg5l97gE15um+ekwmAxk9 P2XHrJbsenr95c9gnfEeke/L9Gmn6od+qz2IRcSkgdvrETQtKxEl53E5b5bzPHYz x16H4RXMH0Y=

On 10/09/2015 12:02, Garnizov, Ivan (RRZE) wrote:

You have it correctly understood.  It is indeed the case that if you run bidirectional from one host (say A) then you will end up with results between A and B (both directions) on MA of host A. And if you have no measurements scheduled on host B then you will end up with no graphs there.

The explanation is very simple: it is the scheduler that collects and stores the results in the MA, not the measurement tool.

Based on that principle you can deduce where you results are being collected and presented from.

Thanks.

So now I have this problem: I want to set up a disjoint mesh like this

   B1 B2
A1 x  x
A2 x  x
A3 x  x
A4 x  x

B1 and B2 are two perfsonar nodes I control. A1-A4 are remote hosts run by other people.

Now, the default is that the mesh configuration would assign host A to run test A->B, and host B to run test B->A. But since A1-A4 are not reading my mesh configuration, those tests won't be created. As a result I only get the results in one direction.

So now I configure "force_bidirectional 1". This means I get the tests run both ways, and stored on the B node. That's fine.

However, maddash needs to know which MA to read. Each "host" A1-A4 is only configured with a single MA. That MA URL can't be the A host itself; none of my test data is stored there.

So I associated those hosts instead to the B1 measurement archive, like this:

        <host>
              description Foo
              address a1.example.com
              <measurement_archive>
                  type        perfsonarbuoy/bwctl
                  read_url    http://b1.example.com/esmond/perfsonar/archive
                  write_url   http://b1.example.com/esmond/perfsonar/archive
              </measurement_archive>
              <measurement_archive>
                  type        traceroute
                  read_url    http://b1.example.com/esmond/perfsonar/archive
                  write_url   http://b1.example.com/esmond/perfsonar/archive
              </measurement_archive>
        </host>
        <host>
              description Washington
              address wash-owamp.es.net
              <measurement_archive>
                  type        perfsonarbuoy/owamp
                  read_url    http://b1.example.com/esmond/perfsonar/archive
                  write_url   http://b1.example.com/esmond/perfsonar/archive
              </measurement_archive>
        </host>

This works for a1->b1. However for tests a1->b2 it means that it tries to read the data from b1, and finds nothing there. You can see this currently in the the right-hand column of the grid at http://maddash-uon.kenet.or.ke/maddash-webui/index.cgi?grid=KENET%20Mesh%20Config%20-%20Core%20to%20External%20Throughput%20Testing



(Possibly it also configures these tests to run on b2 and *write* data on b1. And maybe if I set up suitable authentication from b2 to b1 it would work! But this would be confusing as hell, and essentially forces me into deploying a central MA to be usable

So for now we will remove the second column - unless there is a better solution to this?

Supplementary question: the disjoint group has a_member and b_member hosts. And each host has its own read_url and write_url. Are the tests written to the a_member host's write_url, or the b_member host's write_url?

Thanks,

Brian.




Archive powered by MHonArc 2.6.16.

Top of Page