Hi!
> > 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!!
For what it is worth, ping while under load looks (downloading linux
kernel, as always) like this:
root@bug:~# ping 192.168.55.100
PING 192.168.55.100 (192.168.55.100): 56 data bytes
64 bytes from 192.168.55.100: icmp_seq=0 ttl=32 time=519.0 ms
64 bytes from 192.168.55.100: icmp_seq=1 ttl=32 time=640.1 ms
64 bytes from 192.168.55.100: icmp_seq=2 ttl=32 time=760.0 ms
64 bytes from 192.168.55.100: icmp_seq=3 ttl=32 time=840.0 ms
64 bytes from 192.168.55.100: icmp_seq=4 ttl=32 time=989.2 ms
64 bytes from 192.168.55.100: icmp_seq=5 ttl=32 time=641.6 ms
64 bytes from 192.168.55.100: icmp_seq=6 ttl=32 time=820.0 ms
64 bytes from 192.168.55.100: icmp_seq=7 ttl=32 time=1000.2 ms
64 bytes from 192.168.55.100: icmp_seq=8 ttl=32 time=689.8 ms
64 bytes from 192.168.55.100: icmp_seq=9 ttl=32 time=859.8 ms
64 bytes from 192.168.55.100: icmp_seq=10 ttl=32 time=830.0 ms
64 bytes from 192.168.55.100: icmp_seq=12 ttl=32 time=679.9 ms
64 bytes from 192.168.55.100: icmp_seq=13 ttl=32 time=239.8 ms
64 bytes from 192.168.55.100: icmp_seq=14 ttl=32 time=530.0 ms
64 bytes from 192.168.55.100: icmp_seq=15 ttl=32 time=620.0 ms
64 bytes from 192.168.55.100: icmp_seq=16 ttl=32 time=700.0 ms
and ping when links is idle looks like this:
root@bug:~# ping 192.168.55.100
PING 192.168.55.100 (192.168.55.100): 56 data bytes
64 bytes from 192.168.55.100: icmp_seq=0 ttl=32 time=117.2 ms
64 bytes from 192.168.55.100: icmp_seq=1 ttl=32 time=110.1 ms
64 bytes from 192.168.55.100: icmp_seq=2 ttl=32 time=110.0 ms
64 bytes from 192.168.55.100: icmp_seq=3 ttl=32 time=110.1 ms
64 bytes from 192.168.55.100: icmp_seq=4 ttl=32 time=110.1 ms
64 bytes from 192.168.55.100: icmp_seq=5 ttl=32 time=110.1 ms
64 bytes from 192.168.55.100: icmp_seq=6 ttl=32 time=110.0 ms
64 bytes from 192.168.55.100: icmp_seq=7 ttl=32 time=109.8 ms
64 bytes from 192.168.55.100: icmp_seq=8 ttl=32 time=110.1 ms
64 bytes from 192.168.55.100: icmp_seq=9 ttl=32 time=110.0 ms
64 bytes from 192.168.55.100: icmp_seq=10 ttl=32 time=110.1 ms
64 bytes from 192.168.55.100: icmp_seq=11 ttl=32 time=110.0 ms
> Conclusion is:
> 3. Or receiver has totally broken TCP, which sends delayed ACKs
> ~500msec after packet arrives, even if another packets
This is windows ce stack; quite likely to be broken. I doubt it ever
announces window bigger than 3100 (is there way to make it make its
window bigger?).
> 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.
This is well possible. Their TCP stack is probably designed to work at
19200. Is there way for us to missbehave? Ie. what would happen if I
forced linux tcp stack to think their window is bigger than it really
is? [Is there easy way to break my tcp stack this way?]
Pavel
-- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org- 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:21 EST