SUMMARY: Tuning the tu: tulip Ethernet buffers

From: Iain Barker (ibarker@aastra.com)
Date: Tue Jan 20 2004 - 08:43:00 EST


Thanks to Dr. Blinn who provided the following hint:

>On my V5.1B system I see:
>
>pc164lx (root) # sysconfig -q tu
>tu:
>StoreAndForward = 0
>delay_6694F = 1
>
>There might be a way to tweak the initial value with "dbx" if you
>had kernel sources to reference and knew what you were doing.

Thanks to John Lanier who provided the dbx information:

>The following write-up was forwarded from the HP Tru64 Network Team:
>
>The message "tu0 transmit fifo underflow:threshold raised to 256 bytes" means
>that the ethernet controller tu was sending characters faster than the PCI
>bus could fill the transmit FIFO. So the controller raised the threshold for
>how much data gets put in the FIFO before it starts transmitting.i.e., the
>controller is dynamically adjusting itself to optimize network throughput.
>
>But does this mean that I lost some packets? When the device can't get enough data
>to transmit, it "jams" the frame it's currently transmitting (which makes it
>appear to be a CRC and/or Frame error). In general, Ethernet is a datagram
>medium, and no datagram transmit is ever guaranteed to make it to the destination.
>
>Store-forward mode is never an issue in 10mb mode but it is in 100mb. Store-forward
>mode insures that the entire packet is in the chip BEFORE the transmit starts
>because some systems cannot DMA data fast enough to the chip in 100mb mode.
>
>Basically, the system cannot keep up with the chip. The customer needs to run
>with store-forward enabled to avoid the fifo underflow.
>
>To enable store-forward mode when the tu driver starts,
>patch the variable "tu_sf_mode" using dbx.
>
>EX:
>====
>
># dbx -k /vmunix
>
>(dbx) print tu_sf_mode
>0
>
>(dbx) patch tu_sf_mode=1
>1
>
>(dbx) print tu_sf_mode
>1
>
>(dbx) quit
>
>**************
>
>You may want/need to restart the network (#/usr/sbin/rcinet restart)

To survive a reboot, use the dbx 'assign' command rather than 'patch'

There is also the option of changing to use DE60x interface instead of the DE50x.
The DE60x does not suffer from the buffering problems caused by the delay_6694F patch.

-----Original Message-----

On Tru64 4.0f I am getting the following messages during heavy IP traffic:

tu0: transmit FIFO undeflow: threshold raised to : 256 bytes
tu0: transmit FIFO undeflow: threshold raised to : 512 bytes
etc.

Each time the buffer is increased, data trasnfers are interrupted for a short time.

Is there any way to pre-configure the FIFO to a larger size?
Perhaps via sysconfig or an option during a kernel build perhaps?

thanks.



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:49 EDT