linux-mips
[Top] [All Lists]

Re: [2.4 PATCH] pcnet32.c - tx underflow error

To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error
From: Jun Sun <jsun@mvista.com>
Date: Wed, 10 Jul 2002 16:51:45 -0700
Cc: linux-mips@oss.sgi.com, Ralf Baechle <ralf@oss.sgi.com>, marcelo@conectiva.com.br
References: <E17SRFB-00087H-00@the-village.bc.nu>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Alan Cox wrote:

This patch fixes a tx underflow error for 79c973 chip. It essentially delay the transmission until the whole packet is received into the on-chip sdram.

The patch is already accepted by Marcelo for the 2.4 tree, I think.


Which slows the stuff down for people with real computers.


Contrary to what it might appear at first glance, it does not really.

While it delays the start of a transmission of the first packet, the delay does not aggregate in a steam of data. The bottle neck is either in upper layer (how fact upper layer generates packets) or in the link layer (when we exceed the maximum bandwitch of the wire, in which case we always have plenty of full packets to send).

The delay itself is small (should be < 100us typically). So there is no impact on interactive packets. Note if the delay is not small (e.g., on system where PCI bus arbitration may be broken), then you *will* have the tx underflow problem.

So on a good system the delay should be really small (especially if you compare to what it takes to transmit the whole packet to the other end). On a bad system where the delay can be long, then you will need the fix anyway.

Jun

Please apply
some kind of heuristic to this - eg switch to delaying if you exceed
50 failures in a 60 second period.

Alan




<Prev in Thread] Current Thread [Next in Thread>