kuznet@ms2.inr.ac.ru wrote:
> > binary trace with "tcpdump -n -w" is attached,
>
> I am afraid you forgot it.
I have attached various files to this message. Hopefully the names make
it clear which they are.
> > I am wondering if not sending so many duplicate ACKs would help the
> > broken sender (I know, that is against RFC793 but hey if it works...).
> If it works, hack kernel not to send dupacks. What is the problem? :-)
I hate rebooting :-)
> Yes, on such links fast retransmit is not useful in any case.
Should I turn of /proc/sys/net/ipv4/tcp_fack then?
> Actually, you can make something from your side: if rtt is so high,
> most likely this means excessive queueing.
Yes, definitely. Btw, I saw a ping round trip time of 162s just now.
> You can fight this
> advertising smaller window (f.e. adding option "window N" to route).
> If intepacket gap is 5sec and rtt 23, you can divide window by 23/5
> and rtt should drop to some more reasonable number. "Theoretical"
> bandwidth will reduce, but practical will grow.
>
>
> > For the sake of a Linux test, I shall try proxying this stream via a
> > Linux 2.4.2 box I have on the net, and see if it is an improvement.
>
> Yes, it is intersting.
I've tried it, with no special settings (mtu or window or sack etc.) at
either end. Local end is Linux 2.4.7, remote is 2.4.2-2 from Red Hat 7.1.
The remote is proxying a connection to the final mailserver.
I saw very few retransmits in a single message download. SACK appears
occasionally. I don't really understand the local reaction to SACK, or
why a SACK option appears in one ACK sent locally and not the following
ACK, even though the SACK mentions data that does not arrive between the
two locally sent ACKs.
The throughput difference was obvious: POP3 negotiation + 30k message +
headers took:
5 min 31 sec downloading unknown OS -> Linux 2.4.7
2 min 15 sec downloading Linux 2.4.2 -> Linux 2.4.7
Looking at the traces, I expect the improvement on the straight data
part is better than 2:1, because I saw so many retransmits with the
other OS and hardly any with Linux as the server.
If someone would like to do an OS type probe on sdps.demon.co.uk, we
will know which OS should be avoided for this kind of connection ;-)
It is still very slow considering it is advertised as "9600 baud" though
:-(
cheers,
-- Jamie
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:12 EST