[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Understanding flow control

From: Tom Gross
Subject: Re: [Discuss-gnuradio] Understanding flow control
Date: Fri, 15 Jan 2010 14:47:22 -0500

Thanks Eric, that's exactly what I thought.  I think in our
application it's probably better to drop data, or at least that's why
things are more stable for us when RX is OFF.  Or maybe we should just
slow down a bit.  Something to think about.

On Fri, Jan 15, 2010 at 2:07 PM, Eric Blossom <address@hidden> wrote:
> On Fri, Jan 15, 2010 at 01:54:24PM -0500, Tom Gross wrote:
>> I guess I could study the firmware source (if it's in the C code where
>> this happens) to figure out what happens if RX is OFF.  My assumption
>> is that somewhere in the USRP2 code there is some recognition that it
>> can't keep up with transmit data, thus causing it to send pause
>> signals back to the ethernet controller (is that correct?).  Maybe
>> it's not in the firmware but built into some ethernet port controller
>> chip.
> Actually, PAUSE handling is all handled in the FPGA.  When the FIFO is
> getting full, a PAUSE frame is sent on the wire telling the host to
> stop sending for a while.
>> Or maybe my understanding of what RX ON/OFF does is completely wrong.
>> :-)  So, I guess I'm asking: as I understand it, the USRP2 sends pause
>> packets (or something) to the ethernet controller when it can't keep
>> up with data being sent to it.   RX ON means that the controller will
>> acknowledge these pause commands and stop sending data.  Or have I got
>> that completely backwards?
> In ethtool lingo, "Rx ON" means that the host will listen to the PAUSE
> frames.  This is what we want. Otherwise the host will continue
> blasting away, and they'll get dropped somewhere along the way.  "Tx
> OFF" means that the host does not send PAUSE frames.  This is what we
> want.  The USRP2 never listens to PAUSE frames, since it doesn't have
> enough buffer to avoid an overrun.
> We're using "Asymmetric flow control".  See also:
>  http://grouper.ieee.org/groups/802/3/z/public/presentations/nov1996/asym.pdf
> Eric

reply via email to

[Prev in Thread] Current Thread [Next in Thread]