Steve Dodd <[EMAIL PROTECTED]> to Andrea Arcangeli <[EMAIL PROTECTED]>
on Thu, 7 Oct 1999 21:01:08 +0100
On Thu, Oct 07, 1999 at 03:29:26PM +0200, Andrea Arcangeli wrote:
>> Agreed your first trace shows that the TCP stack of the linux-sending-side
>> is fine. It's the the hardware layer that is dropping packets.
>*nods* It doesn't seem to depend on the equipment at the far end of the link,
>so I'm guessing it's a local problem. The modem here is part of a 3Com

After looking at all the mail written on the topic I have some
explanation what maybe happens. In case data is too long for
single packet it it split to fragments, and - although I don't
know the code which is just in Linux, I suppose there is some
program which does it - it gets buffer with a data to be sent,
and either passes the buffer to driver to be sent as single
packet, or allocates buffers and puts fragments in them, and
maybe number of buffers it can allocate is driver parameter.

Now little imagination:
- driver has no buffers to assign (transmit queue is full)
  in such a case the "splitter" simply decides it cannot
  process data, and waits for buffer to become available
- driver finishes packet sending, and frees one buffer
  the "splitter" puts data in the buffer, as much as it
  can, and wants next buffer for next fragment; but the
  driver still has no free buffers - it sends much slower
  than the "splitter" processes data, therefore it cannot
  finish netx buffer during the time; the "splitter" has
  no possibility to pause its processing in middle of the
  data, nor can it abort the buffer sent to driver - the
  only possibility is to lose remaining data.

Is such a scenario possible? Most likely it is a bit more
complicated - you were able to dump packets from further
parts of "splitter" output, therefore they are lost after
its processing, but they do not enter driver xmit queue.

Is there a quick method to find if it is in your case?
I suppose there are counters of packets processed by the
driver, and looking at these counters can give the answer.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to