Re: [Discuss-gnuradio] Understanding flow control

[Tom Gross]

That's very interesting... just this morning we were playing with
turning rx OFF with ethtool
and convincing ourselves that it seemed to stabilize our system.

If we turn off RX pause (ethtool -A eth0 rx off), does the USRP2 stop
sending pause frames?

We are running two USRP2s connected with a MIMO cable. The master
USRP2 receiving
and transmitting data while the slave USRP provides a second source to
the host (on eth1).

(without going into details of our application which I don't
understand - I'm just the
programmer), we are munging the data received on the two channels and sending
it right back to eth0.  sometimes the system is stable but very often
it seems to get
into this state where it is stable for 30 seconds and then "blows" up
in the host code.

suspecting it had something to do with ethernet traffic I was fooling
about with ethtool
and found that things were much more stable with RX OFF on eth0.  or
it was when I last
saw it running. :-)

so I guess my question is: is there anything in host code or usrp2
firmware that behaves
differently if RX pause is off?


On Thu, Jan 14, 2010 at 7:18 PM, Eric Blossom <address@hidden> wrote:
> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>