perfSONAR User Q&A and Other Discussion

[Andrew Lake <>]

Hi Roderick, Pol,

Lots of questions in these threads, so sorry if I miss any but I'll try to 
hit every thing below:

- The error "bwping question - Unable to open control connection" means that 
the other side does not have bwctld running. A lot of owamp hosts explicitly 
turn bwctld off since they are dedicated to only owamp measurements. The 
addition of bwctl being able to run the owping command is relatively recent 
so this is especially true. I believe this is the case with your 
owamp.seat.net.internet2.edu example. 

- The "bwctl: local tool exited before expected with status=1" error to the 
XSEDE host I am less sure about. Firewall maybe? Aaron Brown might have a 
better idea, but he is out of the office for the day. 

- Try "bwping -T owamp -c chic-pt1.es.net". I believe all the esnet  boxes 
with -pt1 in the name have both bwctl and owamp. If you go to 
http://stats.es.net/ServicesDirectory/ and type "es.net" in the search box 
you should get a full listing under the BWCTL heading.

- As for Pol's question about whether bwctl and owamp communicating their 
schedules to each other, the answer has changed from a simple "no" of a few 
months ago to "it depends". In the case of on-demand bwping commands from the 
command line, bwctld does coordinate the schedule for both the owamp test and 
throughput tests. The owamp test run in this case usually sends 100 packets 
or so over the course of a few seconds (depending on the parameters you give 
it). In other words, it runs for a finite amount of time. When you set-up a 
regular test via the Toolkit GUI or the mesh config though, it starts a type 
of owamp test that is always running. In this case owamp is running 100% of 
the time which means when bwctl runs it has the potential to interfere with 
the owamp results. It is desirable to run owamp like this because it allows 
you to catch loss events, short-lived path changes and other things you could 
easily miss just doing one-off tests. Other approaches do exist each with its 
strength's and weaknesses but this is the approach the toolkit has taken. As 
such, having two boxes is the lowest risk method of ensuring your results are 
not tainted currently. 

- A few things worth mentioning that are in the pipeline for 3.4 (a release 
candidate of which just came out). First, bwctl will be registering what 
tools it supports in the lookup service, so issues like trying to figure out 
where you can run bwping become easier to answer. Also, ESnet, IU NOC and 
others are in the middle of testing a dual-interfaced host that runs bwctl 
and owamp on separate interfaces. We are still investigating what 
ramifications this has on the results. There is a script which is in the 
middle of being documented that helps configure the routing for this type of 
setup on 3.4. Finally, the 3.4 graphs will be capable of displaying bwctl and 
owamp results on the same graph which should make it somewhat easier to see 
conflicts that arise from running both on the same host

Let me know if I missed something and hopefully that answers the questions.

Thanks,
Andy

On Jul 25, 2014, at 2:51 AM, "Roderick Mooi" 
<>
 wrote:

> Hi Pol
> 
> I had a similar problem recently. Look for this thread in the mailing list: 
> "bwping question - Unable to open control connection". It may help.
> 
> I haven't gotten to testing the new version of bwctl Aaron proposed but if 
> you do please let us know how it works.
> 
> Regards,
> 
> Roderick
> 
>>>> On 2014-07-24 at 21:55, Pol Llovet 
>>>> <>
>>>>  wrote:
>> Hello!
>> 
>> I recently attended the PS tutorial at XSEDE and we have been charging
>> ahead with it here at MSU.  We now have 2 servers (soon to be 3) that are
>> testing bandwidth from the edge, behind the firewall, and deep in the
>> network.  We don't have any owamp nodes yet, but this leads me to my
>> question:
>> 
>> The reason that we would need those owamp nodes is because we were told
>> that the scheduler for owamp tests and bwctl tests don't communicate so you
>> run the risk of the tests happening on top of one another and getting bad
>> data. However, it seems like there are terminal versions of the tests that
>> can be run safely (bwping, bwtraceroute).  Am I correct in that assumption?
>> 
>> I have tried running bwping with -T owamp, but I have been unable to have a
>> successful test.  For example:
>> 
>> [root@status
>>  pol]# bwping -T owamp -c owamp.seat.net.internet2.edu
>> bwping: Unable to connect to owamp.seat.net.internet2.edu
>> 
>> This test does seem to get scheduled if I use ps.tacc.xsede.org as the
>> target, but I get the following result:
>> 
>> SENDER START
>> owping: FILE=owping.c, LINE=1603, Unable to open control connection to
>> [129.114.0.189]:5774.
>> bwctl: local tool exited before expected with status=1
>> 
>> When I go to http://ps.tacc.xsede.org/toolkit/ it looks like owamp is on
>> port 861, but that errors out entirely when I try to use the same command
>> with ps.tacc.xsede.org:861.
>> 
>> So, can we use bwping with owamp? Or is this just a placeholder for later
>> functionality?
>> 
>> thanks in advance,
>> 
>> pol
>> 
>> Pol M. Llovet
>> Research Computing / Middleware
>> Montana State University
>> w: 406-994-3416
>> c: 406-646-6747
>> 
>> -- 
>> This message is subject to the CSIR's copyright terms and conditions, 
>> e-mail 
>> legal notice, and implemented Open Document Format (ODF) standard. 
>> The full disclaimer details can be found at 
>> http://www.csir.co.za/disclaimer.html.
>> 
>> This message has been scanned for viruses and dangerous content by 
>> MailScanner, 
>> and is believed to be clean.
>> 
>> Please consider the environment before printing this email.
> 
> 
> -- 
> This message is subject to the CSIR's copyright terms and conditions, 
> e-mail legal notice, and implemented Open Document Format (ODF) standard. 
> The full disclaimer details can be found at 
> http://www.csir.co.za/disclaimer.html.
> 
> This message has been scanned for viruses and dangerous content by 
> MailScanner, 
> and is believed to be clean.
> 
> Please consider the environment before printing this email.
>