TCP Performance

Tue Sep 3 09:18:01 UTC 2013

Try your iperf over port 80 and see if your hitting any website related
filters. At least rule it out.

Or try HTTP on a different port.

If your iperf test is getting link speed then you can rule most things
connection related. I really think some device is QoS'ing packets bound
to<>from port 80.

On Tue, Aug 27, 2013 at 12:22 PM, Nick Olsen <nick at flhsi.com> wrote:

> I have indeed tried that. And it didn't make any difference. Functionally
> limiting each router port to is connected microwave links capacity. And
> queuing the overflow. However the queue never really fills as the traffic
> rate never goes higher then the allocated bandwidth.
>
> Nick Olsen
> Network Operations (855) FLSPEED  x106
>
> ----------------------------------------
> From: "Blake Dunlap" <ikiris at gmail.com>
> Sent: Tuesday, August 27, 2013 1:32 PM
> To: nick at flhsi.com
> Cc: "Tim Warnock" <timoid at timoid.org>, "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: TCP Performance
>
> If you have a router, you can turn on shaping to the bandwidth the link
> will support.
>
> -Blake
>
> On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen <nick at flhsi.com> wrote:
>  I do indeed have stats for "TX Pause Frames" And they do increment.
> However, Our router is ignoring them since it doesn't support flow control.
>
> I guess my next question would be. In the scenario where we insert a switch
> between the radio and the router that does support flow control. Are we not
> only moving where the overflow is going to occur? Will we not see the
> router still burst traffic at line rate toward the switch, Which then
> buffer overflows sending to the radio on account of it receiving pause
> frames?
>
> Nick Olsen
> Network Operations (855) FLSPEED  x106
>
> ----------------------------------------
> From: "Tim Warnock" <timoid at timoid.org>
>  Sent: Tuesday, August 27, 2013 1:08 PM
> To: "Blake Dunlap" <ikiris at gmail.com>, "nick at flhsi.com" <nick at flhsi.com>
>  Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: RE: TCP Performance
>
> > Regardless, your problem looks like either tail drops or packet loss,
> which
> > you showed originally. The task is to find out where this is occurring,
> and
> > which of the two it is. If you want to confirm what is going on, there
> are
>  > some great bandwidth calculators on the internet which will show you
> what
> > bandwidth you can get with a given ms delay and % packet loss.
> >
> > As far as flow control, its really outside the scope. If you ever need
> flow
>  > control, there is usually a specific reason like FCoE, and if not, it's
> > generally better to just fix the backplane congestion issue if you can,
> > than ever worry about using FC. The problem with FC isn't node to node,
> its
>  > when you have node to node to node with additional devices, it isn't
> smart
> > enough to discriminate, and can crater your network 3 devices over when
> it
> > would be much better to just lose a few packets.
>  >
> > -Blake
>
> In my experience - if you're traversing licenced microwave links as
> indicated flow control will definitely need to be ON.
>
> Check the radio modem stats to confirm but - if you're seeing lots of drops
> there you're overflowing the buffers on the radio modem.
>
>
>

-- 
--------------------
Bryan Tong
Nullivex LLC | eSited LLC
(507) 298-1624