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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST