Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 May 1999 17:11:34 -0400
From:      Dennis <dennis@etinc.com>
To:        Wilko Bulte <wilko@yedi.iaf.nl>
Cc:        hackers@freebsd.org
Subject:   Re: What is a "transmit underflow"?
Message-ID:  <199905102218.SAA11495@etinc.com>
In-Reply-To: <199905102100.XAA01411@yedi.iaf.nl>
References:  <Pine.LNX.4.04.9905101243190.13071-100000@feral.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 11:00 PM 5/10/99 +0200, you wrote:
>As Matthew Jacob wrote ...
>
>> This almost always happens for tulip chips && and alpha platforms and Matt
>> Thomas' de driver.
>
>I have also seen it quite often on i386, it is not limited to alpha
>
>> On Tue, 11 May 1999, Peter Wemm wrote:
>> 
>> > Matthew Dillon wrote:
>> > > :Hi, all.
>> > > :
>> > > :I've got two FreeBSD boxes (3.1-R) working as routers, one with two
4-port
>> > > :ZNYX 10/100 ethernet cards and the other with one of those cards. The
>> > > :cards have DEC chips (21140A).
>> > > :
>> > > :The routers are working perfectly, but from time to time I get the
>> > > :following messages:
>> > > :
>> > > :de0: abnormal interrupt: transmit underflow (raising TX threshold
to 96|256)
>> > > :de1: abnormal interrupt: transmit underflow (raising TX threshold
to 96|256)
>> > > :
>> > > :What do they mean? Everything seems to be OK, but I'd like to know
wether
>> > > :I have to worry about this or not.
>
>Not to worry, it keeps working just fine in my experience. 
>
>Groeten / Cheers,

In case some of you care, here is what it is. The proper term is
"transmitter underrun", but that is not really important.

Once a frame has begun transmission (and this goes for HDLC and other
continuous packet protocols as well), all of the bytes of the frame/packet
must be in contiguous time slots until the complete end of frame has been
sent. With a bus master, the board must be able to fetch the data from
system memory in time to fill all the slots. If the device cannot get the
bus (usually because some other device has it) in time to fill the slot,
then the frame must be aborted and an underrun occurs. If you get a lot of
these it basically means that  you are out of bus bandwidth or that some
other device is hogging the bus. This is typically why you will start to
lose packets, no matter how fast your CPU is, at some point where
contention for the bus is too high. Since most devices give priority to the
receiver, problems usually manifest themselves as transmitter underruns first.

Dennis
Emerging Technologies, Inc.




http://www.etinc.com
ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
HSSI/T3 UNIX-based Routers
Bandwidth Manager 



http://www.etinc.com/bwmgr.htm


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905102218.SAA11495>