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 <n...@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" <iki...@gmail.com> > Sent: Tuesday, August 27, 2013 1:32 PM > To: n...@flhsi.com > Cc: "Tim Warnock" <tim...@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 <n...@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" <tim...@timoid.org> > Sent: Tuesday, August 27, 2013 1:08 PM > To: "Blake Dunlap" <iki...@gmail.com>, "n...@flhsi.com" <n...@flhsi.com> > Cc: "nanog@nanog.org" <nanog@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
