TCP Performance

Tue Sep 3 09:24:09 UTC 2013

I mean programatically speaking your network equipment generally knows no
difference between and HTTP packet and an IPerf packet. (Layer 3 packet
forwarding only breaks the first 84 bits off the header, Layer 2 gets 52
bits (with a vlan tag))  So, unless QoS of some kind gets brought into the
picture the protocol shouldnt make a difference, however, if something is
examining the packets further than that it could also be causing your
throughput issues. Also, keep in mind some switches ship with QoS enabled
for VoIP etc.

Might be something to check into further.

On Tue, Sep 3, 2013 at 3:18 AM, Bryan Tong <contact at nullivex.com> wrote:

> 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
>

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