perfSONAR User Q&A and Other Discussion

[Brian Tierney <>]

On Mon, Jun 20, 2016 at 6:51 AM, Brian Candler <> wrote:

On 20/06/2016 10:10, Brian Tierney wrote:

That is a somewhat common pattern if there is a device in the path with buffers that are too small.

You can config perfsonar to use a smaller buffer using the GUI, or editing the mesh config file.

By "smaller buffer" do you mean smaller TCP window size?

I mean the switch buffer, as described here:

http://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/

and

http://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/switch-buffer-testing/

  

I note that in the reported stats there are no retransmissions reported (Retr = 0); so what's the mechanism by which an intervening device could reduce the throughput to the given value, without dropping packets?

I also see that the congestion window has ramped up to 21.8MB and stuck there. I don't know what the RTT is between those two endpoints, but let's say it's 70ms for sake of argument. That would imply a throughput of about 2500Mbps I think. (1000/70 * 21.8 * 8)

Is it possible that the window size at the other end is set lower than expected? Perhaps if the OP captured the initial TCP SYN exchange it would make this clear (remembering to decode the TCP window scaling factor)

That seems like a likely possibility too.

 

Also, the OP said that applying the -w option (without saying the value used) could achieve a higher throughput. So it should be possible to compare the TCP SYN exchange, with and without the -w option, to see what's different.

Regards,

Brian Candler.

--

Brian Tierney, http://www.es.net/tierney
Energy Sciences Network (ESnet), Berkeley National Lab
http://fasterdata.es.net