[ 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.
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!!
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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