Looking at the complete dump on the server more closely I see what's happening. The server didn't jump ahead in the stream. The client side of these tests is on a fractional T1. In about 60Ms the server pushed a window's worth of data, about 200 packets since the payload was small, 48 bytes. (48 + IP + TCP) * 200 is around 17KB in 60Ms which overflowed the frame switch queue.
The other part of the dump where the server is acked for a segment just sent but does not send the next segment till a duplicate ack is received better than a second later is still suspect to me. John Capo Quoting Sergey Babkin ([EMAIL PROTECTED]): > > And here a _very_ pathological thing has happened: the server > just forgot to send the data between sequence numbers 12937 > and 28049. Since the dump was done on the server side, this suggests > that something very bad has happened with the TCP state on > the server side. Possibly the value of the current sequence number > in the protocol control block got overwritten by something. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
