Re: [Discuss-gnuradio] Understanding flow control

[Eric Blossom]

On Thu, Jan 14, 2010 at 02:13:01PM -0500, Charles Irick wrote:
> Hello,
> I'm trying to understand the flow control between the USRP2 and host
> machine. I assume that it needs to be worked out where the USRP2 will
> always have a constant stream of uninterrupted radio data when sending
> and receiving (unless a more complex radio is in place which allows
> the signal to drop).
> 
> I have read that overruns are not really an issue, is this due to the
> processing power/throughput of the spartan 3 vs the host processor?
> 
> I see that pause frames are used to help with flow control but I can
> only see this being used if an overrun or full fifo has occured on the
> USRP2, what happens if the fifo becomes empty?
> 
> I'm trying to catch the pause frames with tcp dump and i'm either
> doing it wrong or they are not happening. I have tried usrp2_siggen
> and usrp2_fft. I'm using the dev code from git on ubuntu 9.04 with
> gnuradio 3.2.2
> 
> We are either overflowing, underflowing, or are perfectly in sync.
> Only overflow with pause frames to control makes sense to me. If this
> is not the case an explanation would be very much appreciated.
> 
> Charles

The USRP2 only applies backpressure to data transmitted from the host.
It does this by transmitting PAUSE frames, which timeout after a
certain period of time (see the the Gig E spec for details).

In the FPGA -> host direction, there is no flow control since it is
rate limited by the baseband rate that the host has requested.  If the
host asks for a higher rate than the host can handle, the host is in
error.  There's no amount of flow control and buffering that can fix
that symptom.

If you want to force the USRP2 to generate pause frames, just use
usrp_siggen.py

Also, with most NIC's you can confirm that asymmetric flow control has
been negotiated using $ ethtool -a <ethN>.
It should report Rx: On, Tx: Off

Eric