nanog mailing list archives
Re: TCP Performance
From: Bryan Tong <contact () nullivex com>
Date: Tue, 3 Sep 2013 03:18:01 -0600
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 () 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 () gmail com> Sent: Tuesday, August 27, 2013 1:32 PM To: nick () flhsi com Cc: "Tim Warnock" <timoid () timoid org>, "nanog () nanog org" <nanog () 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 () 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 () timoid org> Sent: Tuesday, August 27, 2013 1:08 PM To: "Blake Dunlap" <ikiris () gmail com>, "nick () flhsi com" <nick () flhsi com> Cc: "nanog () nanog org" <nanog () nanog org> Subject: RE: TCP PerformanceRegardless, your problem looks like either tail drops or packet loss,whichyou showed originally. The task is to find out where this is occurring,andwhich of the two it is. If you want to confirm what is going on, thereare > some great bandwidth calculators on the internet which will show you whatbandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever needflow > control, there is usually a specific reason like FCoE, and if not, it'sgenerally 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 smartenough to discriminate, and can crater your network 3 devices over whenitwould be much better to just lose a few packets.>-BlakeIn 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
Current thread:
- Re: TCP Performance Bryan Tong (Sep 03)
- Re: TCP Performance Bryan Tong (Sep 03)