On Thu, May 16, 2013 at 07:41:41AM +0200, Otto Moerbeek wrote:
> On Wed, May 15, 2013 at 08:54:02PM +0000, Stuart Henderson wrote:
>
> > On 2013-05-15, Adam Atkinson <gh...@mistral.co.uk> wrote:
> > > Stuart Henderson wrote:
> > >
> > >> Two pairs of per-packet load balanced (slow) ADSLs, round robinning
> > >> connections
> > >> between the pairs to avoid *too* many problems.
> > >
> > > Is ppp multilink an option? (I have used this on pairs of ADSLs but it
> > > could be that the service provider needs to co-operate, and if the up
> > > and down speeds are very different it can be a bit odd.)
> >
> > Unfortunately not an option.
> >
> > I probably either need to fiddle things in the tcp stack, or have something
> > sitting
> > on a divert socket to buffer up to a certain point and try to forward the
> > packets
> > onward in-order. It's probably not a million miles away from PF's fragment
> > cache
> > though (but for whole packets not frags).
>
> I'm trying to understand what problem you are trying to solve. TCP is
> already designed to deal with out-of-order packets. By themselves,
> out-of-order packets are not a problem. If selective acks are used,
> the amount of retransimission should be relatively low.
>
> Do you have numbers on the amount of duplicate data that is being sent
> (because of out-of-order packets)?
>
> -Otto
I see you posted some data in your initial post:
62653661 packets received
25373283 acks (for 43239433893 bytes)
2225419 duplicate acks
20139430 packets (21139432159 bytes) receivedin-sequence
989606 completely duplicate packets (299125194 bytes)
51753 old duplicate packets
362 packets with some duplicate data (144255 bytes duplicated)
15927761 out-of-order packets (19170915512 bytes)
28812 packets (28812 bytes) of data after window
28812 window probes
259673 window update packets
38231 packets received after close
21 discarded for bad checksums
26790492 packets hardware-checksummed
So about 1 percent of packets get retransmitted. That is not very much.
The amount of duplicate acks is indeed a bit high (8%). I don't know
if that is always the case when SACKs are being used.
Is SACK being used? netstat -s gives some data on SACK activity.
netstat -s on the sending side might also give some more clues.
net.inet.tcp.sackholelimit
might have some influence, but I never played with it and it does not
seem to be documented. But anyway, first check to see if SACK is being
used.
-Otto
