[165246] in North American Network Operators' Group
RE: TCP Performance
daemon@ATHENA.MIT.EDU (Tim Warnock)
Tue Aug 27 13:08:45 2013
From: Tim Warnock <timoid@timoid.org>
To: Blake Dunlap <ikiris@gmail.com>, "nick@flhsi.com" <nick@flhsi.com>
Date: Tue, 27 Aug 2013 17:07:00 +0000
In-Reply-To: <CAJvB4tmNEektrpUj0C-PKEKv7rpn5t4VcOEbUa1i9jbUghrjKA@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> Regardless, your problem looks like either tail drops or packet loss, whi=
ch
> you showed originally. The task is to find out where this is occurring, a=
nd
> which of the two it is. If you want to confirm what is going on, there ar=
e
> some great bandwidth calculators on the internet which will show you what
> bandwidth you can get with a given ms delay and % packet loss.
>=20
> As far as flow control, its really outside the scope. If you ever need fl=
ow
> 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, i=
ts
> when you have node to node to node with additional devices, it isn't smar=
t
> enough to discriminate, and can crater your network 3 devices over when i=
t
> would be much better to just lose a few packets.
>=20
> -Blake
In my experience - if you're traversing licenced microwave links as indicat=
ed 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.
