perfSONAR User Q&A and Other Discussion

[Eli Dart <>]

In general, it should be easy to fill a 1G pipe in the LAN, even in the presence of some packet loss.  That same packet loss will almost certainly cause serious performance problems if the cause of the loss is in the path of a long-distance (WAN) transfer.

If you're able to fill the network path with a single TCP stream, and your users are seeing terrible performance over that same path, I would next look at systems and storage (e.g. NFS mounts, single disk spindle somewhere, firewall traversal to get to storage, CPU bound server, filesystem metadata limitations, bla bla bla).

Eli

On Wed, Mar 11, 2015 at 2:39 PM, Pol Llovet <> wrote:

To the best of my knowledge. These are primarily LAN tests, with some WAN tests (depending on specific collaboration efforts). The WAN comes with a huge grain of salt for point in time tests. But the LAN should be a lot more consistent.

If someone says that loading GIS files are unreasonably slow, an I want to rule out the LAN without stuffing perfsonar nodes in every rack... I bring my perfsonar laptop over configured for that subnet and run an hour of bwctl and owamp tests against the science dmz perfsonar node. I am somewhat arbitrarily picking the parameters for the tests, and wanted to see if there were group opinions on the matter.

-p

On Wed, Mar 11, 2015 at 3:21 PM Eli Dart <> wrote:

Hi Pol,

Are your tests traversing the same network path as the data transfers you are trying to emulate?

Eli

On Wed, Mar 11, 2015 at 11:58 AM, Pol Llovet <> wrote:

[apologies for the early send]
... Not convinced that default tests are sufficient to rule out the network.

I was thinking that a battery of different configs for the two tools would be able to give me a more complete picture. However, I'm not sure what those config flags should be.

On Wed, Mar 11, 2015 at 12:55 PM Pol Llovet <> wrote:

Indeed, but I do want to isolate the network in the test (in some cases to remove the variable from the problem space). I'm just not sure (or convinced) that vanilla bwctl and iperf

On Wed, Mar 11, 2015 at 12:40 PM Alan Whinery <> wrote:

On 3/11/2015 8:27 AM, Pol Llovet wrote:
> I have a laptop that I am using to do point in time tests of bandwidth and
> latency in various labs around our campus.  This is mostly to have an
> "apples to apples" test (or at least the closest thing to it I can get).
>
> However, my bandwidth tests are coming up at close to the theoretical
> maximum for TCP/IP over the switch port speed. This isn't really what the
> users are seeing.  Does anyone know of flags I could send to bwctl or owamp
> to more accurately represent different types of traffic (video streams,
> loading a GIS file, rsyncing a giant image or tgz, I/O on lots of small
> files, etc).
>
> Thanks for your help,
>
> Pol Llovet
>

If you want to emulate what users are seeing, you're probably better off
doing what the users are doing, than trying to emulate it with iperf or
nuttcp, etc. I keep a 2 GB file on a well-connected server, with a
fairly fast disk. For a more "real world" test, I tell people to
download that file, which will be subject to more of the pressures and
influences that "real" traffic is subject to.

Or alternately, if you want to match users, have users do iperf or
nuttcp tests. but memory-to-memory throughput tester tests are most
often not going to compare easily with user activity. Iperf/nuttcp show
you what the network can do without the other constraints you
mentioned.  Users have slow disks, constrained network stacks, other
challenges.

--

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

--

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