* James Sutherland (jas88@cam.ac.uk) said:
> Using a larger receive window on the Linux end could help, anyway. Any
> ideas WHY those packets were dropped, BTW?
I think the important part not why they are dropped but why the following
packets are not acked?
> Case 1 looks likely to entail changing the kernel code, which is more
> involved.
>
> > Case 1)
> >
> > 5 packets were dropped by Linux and had to be re-transmitted. This
> > contributed to about 30% of the elapsed time. Looking at the traces in
> > detail, the receiver isn't using multiple ACKS to indicate a dropped
> > packet. Instead, it stops ACKing new packets. The Sun has to timeout
> > (100+ milliseconds), and then send the missing packets. When I've
> > watched a Sun detect a missing packet, it does multiple ACKS of the
> > last good packet to indicate a packet is missing. The Linux box
> > doesn't do that. Delays were from 100 mseconds to 400 milliseconds in
> > this condition. As I said, it happend 5 times (out of 14258 packets),
> > but contributed to 30% of the total time..
When receiving out-of-order packets the SUN ACKs the last in-sequence packet.
This is not SUN technology, it's TCP. It does this to tell the other machine
it's receiving packets but it missed (at least) one. This will prevent the fast
retransmit from kicking in and will force a time out (not good).
Looking over the code really fast (2.2.14.something) all out-of-order packets
should have been acked, as it was expected. If there's a problem in the acking,
it's probably in net/ipv4/tcp_input.c.
Then again, the problem might be somewhere else entirely, but it's a good
start.
Nacho
-
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 : Sun May 07 2000 - 21:00:14 EST