perfSONAR User Q&A and Other Discussion

[Kevin Kawaguchi <>]

Eli,

Thanks for the explanation.  It's common knowledge that packet loss is bad for TCP, but your link explains that in nice detail.  From the sound of it, bwctl interferes with owamp but maybe not so much the other way around?  If that is the case I wouldn't mind adding latency tests and not announcing to our folks they are running or letting them know the tests are prone to false positives (for now they can keep looking at our smokeping machine for delay/variation/loss).

I think I need to find out about how the tests will be separated out if both are configured prior to upgrading to the next version.  I do not want to have to unconfigure then reconfigure the latency tests if we do this work in advance of the new version.  Does anybody know how this will work?

I was reading about bwctl and it appears that there is a client bwping with owamp arguments.  If bwping or owamp knows how to interact with bwctl, can these tests be scheduled with the throughput tests locally on the same interface?  Considering the high IQ of perfsonar developers, I'm guessing there is some good reason the latency tests are not scheduled with the throughput tests.

Thanks,

Kevin.

---

From: Eli Dart <>
Sent: Wednesday, June 04, 2014 9:10 AM
To: Kevin Kawaguchi
Cc:
Subject: Re: [perfsonar-user] owamp vs bwctl

 

Hi Kevin,

When a throughput test runs, it can momentarily saturate the host interface repeatedly (TCP repeatedly sends big bursts, and if you're sending or receiving big bursts you may queue or lose the packets associated with the OWAMP test).

This has several side effects.

One is that it is less likely that you will be able to accurately measure things like queuing in your network with OWAMP - if you've got nondeterministic queuing at the test host, you can't tell what is caused by the host and what is being caused by network conditions.

The second thing is that if OWAMP sees loss at the test host interface, then you'll see packet loss that does not exist in the network - this is also bad in that it reduces OWAMP's utility for measuring network conditions that are harmful to TCP.

The reason that OWAMP is valuable for measuring loss is that the effect of packet loss on TCP performance is catastrophic over greater-than-metro distances:  http://fasterdata.es.net/network-tuning/tcp-issues-explained/packet-loss/  This is the high-order bit for long-distance high-performance TCP. If you've got loss problems, it doesn't matter what else you do unless you fix the loss.  Given that OWAMP is very useful for finding loss, it is very valuable in this context for building and running a network infrastructure that can reliably support high-performance TCP-based data transfers.

Does this help?

Thanks,

Eli

On Tue, Jun 3, 2014 at 6:15 PM, Kevin Kawaguchi <> wrote:

Perfsonar community,

We're looking at expanding our configuration on our perfsonar nodes.  Currently we are doing bandwidth tests and i just added traceroute to mirror bandwidth sites.  We know the warning about meaningless latency results because throughput is running.  We have a few questions to that end.

1. what is meaningless?  Does it mean skewed? or does it mean 'do not use even if some skew is acceptable'?  In the LBL workshop in February, Jason Zurawski had mentioned that latency/jitter/loss is the much more telling test.  Are there more details on the reasoning behind this statement?  We're curious if this, like bandwidth, is just and indicator or if it gets us one step further down the troubleshooting path or what the benefit of latency is over bandwidth.

2. what is the time line for the version that will do a different interface for owamp vs bwctl?

3. if we were to 'add latency test anyways', in the future version would it automatically split out to the new latency interface we bring up or would we have to delete those tests and reconfigure them?  if it would not be wasted time, i'd like to get the latency tests in there while we have some help.

Thanks!

Kevin

​

--

Eli Dart, Network Engineer                          NOC: (510) 486-7600

ESnet Office of the CTO (AS293)                          (800) 333-7638

Lawrence Berkeley National Laboratory 

PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3