> > You _will_ drop it, if txqueue is full. TCP will back off and re-transmit
> > but this will not allow TCP window to grow and you TCP performance will
> > be pretty bad.
>
> Ok, I didn't look at the network code, so I have to take your
>word for it. I would have assumed that the logical thing would be to
>flow control within the network stack (like it's done in IrDA), but it
>seem that I was wrong.
I looked at the code again and tried to trace TCP xmit path. Seems like it
should not
back off because it does check return status of the dev_queue_xmit (send
packet to the driver).
But it does not seem to retry either. Looks like it's just waits for an ack
from the other side which
effectively makes your window equal to 1 segment. In any case small PPP
queue won't make any
good for you.
> > I totally agree with Paul. Just decrease buffering below PPP.
>
> If what you say is true, I should *increase* the buffering
>below PPP to make sure that packet don't get dropped above PPP.
I was under assumption that you know for sure that buffering is bad for you :)
> Think about it : for TCP, it doesn't matter if buffers are
>above or below PPP, what matter is only how many there are. TCP can't
>make the difference between buffers at the PPP and at IrDA level.
> Actually, it's probably better to keep the buffers as low as
>possible in the stack, because less processing remain to be done on
>them before beeing transmitted.
All this depends on what you want to achieve. If you're looking for max TCP
performance. I'd recommend to use tcptrace and see what actually is going on.
May be your RTT is to high and you need bigger windows or may be there is
something else.
Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:46 EST