netdev
[Top] [All Lists]

Re: Slow TCP connection between linux and wince

To: amlaukka@xxxxxxxxxxxxxx (Aki M Laukkanen)
Subject: Re: Slow TCP connection between linux and wince
From: kuznet@xxxxxxxxxxxxx
Date: Sat, 3 Jun 2000 21:31:15 +0400 (MSK DST)
Cc: linux-kernel@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.OSF.4.20.0006022345530.9101-100000@xxxxxxxxxxxxxxxxxx> from "Aki M Laukkanen" at Jun 3, 0 01:18:15 am
Sender: owner-netdev@xxxxxxxxxxx
Hello!


[ BTW you have problems with your mail at helsinki.fi ]

> There was another error in my mail too, 2*130 is indeed over 200 but that
> was irrelevant. However the conclusion seemed correct, delayed acks timing
> out. Could you explain me why the window of 3100 seems to allow 2 packets
> in flight but sender always waits for the next ack?

No, tcpdump shows that sender always has full window.
Receiver always ACKs _previous_ packet.

RTT=0.9sec, window is 2 packets or ~3K, bandwidth is ~3K/sec.
Tcpdump is perfectly smooth and correct except for the rate. 8)

Probably, receiver delays each ACK by 500msec. I have no idea
why it does this, because it is apparently illegal behaviour.
Look:

1 02:59:02.875097 10.0.0.3.www > 192.168.55.100.1029: . 233601:235061(1460) ack 
196 win 16060 (DF)
2 02:59:03.235031 192.168.55.100.1029 > 10.0.0.3.www: . ack 233601 win 3100 (DF)
3 02:59:03.235094 10.0.0.3.www > 192.168.55.100.1029: . 235061:236521(1460) ack 
196 win 16060 (DF)
4 02:59:03.775064 192.168.55.100.1029 > 10.0.0.3.www: . ack 235061 win 3100 (DF)
5 02:59:03.775137 10.0.0.3.www > 192.168.55.100.1029: . 236521:237981(1460) ack 
196 win 16060 (DF)
6 02:59:04.145061 192.168.55.100.1029 > 10.0.0.3.www: . ack 236521 win 3100 (DF)

ACK #4 acks packet #1, sent 0.9sec before this (hence, rtt=0.9sec).
We have two packets in transmit, so that packet #1 reaches receiver not later
than (2*1500)/bandwidth after transmit. If bandwidth is 115Kbaud,
it is not more ~0.3sec. Hence, packet #3 reaches receiver _before_
receiver sent ACK for previous packet!!

Conclusion is:

1. Either link rate is not 115Kbaud, but three times less.
2. Link is busy with another traffic (it is very unlikely,
   timing is very smooth, I see no jitter).
3. Or receiver has totally broken TCP, which sends delayed ACKs
   ~500msec after packet arrives, even if another packets
   arrived during this period. I.e. delays ACK only to delay. 8)
   Probably, this stack even looked as working, if window were >2packets.
   Namely, if it were > bandwidth*0.9sec=~10K nobody
   even would notice this misbehaviour.

> then (when approaching window limit) sender stops sending packets to the
> wire until always a certain point?

You can investigate this. Probably, sender had no data to send
for these 5 seconds. Probably, your sender selected illegal sndbuf,
which is much less than receiver window.



> something but in our tests too, the sender never quite reaches the window
> limit (but this was of course with a bigger window size).

Exactly. sndbuf is selected so that amount of data ready to send
at sender exceeds receiver window, otherwise sender will not able
to utilize network.

Alexey

<Prev in Thread] Current Thread [Next in Thread>