Re: [Discuss-gnuradio] Understanding flow control

[Tom Gross]

Following up on my previous email, thinking about this some more:

I'm guessing that we are sending the USRP2 more data than it can
handle, it is sending pause packets back, which when RX is ON, the
ethernet card recognizes and slows down its output (not knowing
anything about gig-e control flow but this sounds like x-on x-off),
which causes our system to become unstable, BUT when we turn of RX on
the ethernet device, it ignores the pause packets coming back from the
USPR2, and keeps bombarding the USRP2 with transmitter data.

so what happens if we ignore the pause packets? does the USRP2 drop
packets on the floor and just output stuff as fast as it can?


On Thu, Jan 14, 2010 at 7:55 PM, Tom Gross <address@hidden> wrote:
> 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
>>
>