On Tue, Dec 29, 2009 at 03:30:28PM +0100, Kristian Evensen wrote:

Den 29.12.2009 14:36, skrev Jarek Poplawski:

quoted

On Tue, Dec 29, 2009 at 12:16:24PM +0000, Jarek Poplawski wrote:

quoted

On Tue, Dec 29, 2009 at 10:57:48AM +0000, Jarek Poplawski wrote:

quoted

Did you try to turn off TCP window scaling btw? Anyway, under the
tunnel ([2]), when SACK worked, it saved you a lot of retransmits.

Hmm... Actually, after re-checking, there weren't much more of those
retransmits at all. In [1] there was one more packet lost, so it took
a bit longer. In [2] (with SACK) the retransmit started earlier and
the rcv window was unchanged. So, it rather looks like differences
in timing of TCP recovery techniques.

Hmm#2... On the other hand, I can imagine cases with a larger data
loss, where working SACK should really save on retransmits.

Jarek P.

Thanks for all your comments. I have not tried to disable window
scaling, but will try that as soon as possible. I also noticed the
second packet loss in [1], but I don't think it affected the
situation to much. In similar packet captures, the transfer without
the tunnel has only lost one packet and the throughput drop has been
just as significant as in [1]. It rather seems to be, as you point
out, differences in timing of the recovery techniques, probably
between this accelerator and the server.

Then disabling window scaling seems too radical; maybe you should try
with lower tcp_rmem max etc.

However, I find it a bit strange the dupAcks are sent back to the
server. Based on my, I must admit limited, knowledge of
accelerators, they will buffer and ACK packets if they for example
are responsible for retransmissions. But again, maybe it uses the
dupAcks to tell the server to slow down and then simply discards the
retransmitted packet.

I'm not a TCP expert, but IMHO you don't need much knowledge to assess
quality of this accelerator, if you get better results when omitting
it (partly) with a tunnel ;-)

Jarek P.