On Fri, Nov 30, 2001 at 04:28:32PM -0600, Alfred Perlstein wrote: > * Matthew Dillon <[EMAIL PROTECTED]> [011130 16:02] wrote: > > > > Packet loss will screw up TCP performance no matter what you do. > > NewReno, assuming it is working properly, can improve performance > > for that case but it will not completely solve the problem (nothing will). > > Remember that our timers are only good to around 20ms by default, so > > even the best retransmission case is going to create a serious hicup. > > > > The question here is... is it actually packet loss that is creating > > this issue for you and John, or is it something else? The only way > > to tell for sure is to run tcpdump on BOTH the client and server > > and then observe whether packet loss is occuring by comparing the dumps. > > > > I would guess that turning off delayed-acks will improve performance > > in the face of packet loss, since a lost ack packet in that case will > > not be as big an issue. > > I have an odd theory that makes use of my waning remeberence of the > stack behavior, this may be totally off base but I'd appreciate it > if you guys would consider this scenerio if at all to put my mind > at ease. > > I seem to remeber several places in the stack that detect what looks > like a hiccup and immediately begin sending a sequence of ACKs in > order to trigger the other side's fast retrasmit code. One of the > things that I don't remember seeing is that state is persistant.
There isn't anything in the receiver side that does this; ACKs are sent in response to incoming packets. However, state is maintained on the sender side as to whether we are performing fast retransmit or not. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
