Brooks Davis wrote:
On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote:
I have a link which is provided by someone else that is 7 x E1s aggregated.
At leat it looks that way to me when I get to see it. however I have only been able to get
60kB.sec across this, despite having a tcp window size of 131072 bytes..
After investigation it appears that the link is massively re-orderring packets.
groups of upto 10 packets may appear in random order. (Maybe more, bu tI have seen 10)
in fact packets are rarely IN order.
This plays havoc with the tcp sessions.
I was thinking of writing a hacked up version of NATD that
instead of doing NAT, just did a pre-sort on packets from each session, so that the receiver would
see a stream of IN-order packets, with occasional delays.
firstly, does anyone have any tools to do this already (why build when you can borrow)
and secondly, does anyone have any experience with this sort of problem?
I have no control over or access to the link.. all I have is a promise that they will deliver
14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about packet order.
I just get a 100Mb ethernet cable.
Have you tried Andre's TCP reassembly rewrite? He says he saw
significant improvements in the face of major reordering.
I don't think it's a problem with reassembly overhead, but rather a symptom of sender
backoff when confronted with multiple duplicate acks due to the receiver
getting the packets out of order.
I wonder if there's a way to turn off the sender backoff?
http://www.mail-archive.com/freebsd-net@freebsd.org/msg14064.html
These machines are production machines on a custommer site.. running 4.8
it would be significant work to put the rewrite in (to 4.8) and a lot of red tape to
reboot one to the new kernel.. :-/
-- Brooks
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
