Re: [Discuss-gnuradio] Understanding flow control

[Jeff Brower]

Tom-

> Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
>
> We greatly appreciate the information and need to think about stuff on
> our end.  I've been deliberately vague about our application (not that
> I could really explain it even if I felt authorized discuss it).   The
> thing to remember is that we believe (maybe we are fooling ourselves)
> that we see easily reproducible problems when RX is ON but not when RX
> is OFF.
>
> One more question was just sent to me to pass on, while I was
> composing this email:
>
> crazy idea: is there any way to "clock" the host, i.e. keep track of a
> time stamp in the host and gate/trigger the host outputs at a constant
> sample rate that is consistent with the sample rate of the USRP2?
>
> just thought I would throw that out there...

"Clock the host" at multi-MHz rate?  One way would be to connect the A/D 
converter directly to the PC and omit
external radio hardware.  Then you would not need FPGA de-modulation, GbE, etc. 
 That would be a multi-year hardware
and software effort, but sounds like something you and your mystery questioner 
might be willing to take on ;-)

-Jeff

> On Fri, Jan 15, 2010 at 6:24 PM, Matt Ettus <address@hidden> wrote:
>> On 01/15/2010 03:08 PM, Tom Gross wrote:
>>>
>>> yes of course we have two separate gig-e cards.   if the usrp2 is
>>> sending us "pause" commands then it seems evident the usrp2 is having
>>> trouble keeping up, not the computer.
>>
>> First off, the USRP2 will only send pause frames when you are transmitting,
>> not receiving.  Pause frames are not generated due to the USRP2 being unable
>> to keep up.  Pause frames are not generated due to the computer not being
>> able to keep up.  Pause frames are generated as a normal part of the
>> transmission process.  This is fundamental, and you need to understand
>> exactly why.
>>
>>
>>
>> When you are transmitting, the USRP2 can only consume samples at a fixed
>> rate, determined by the clock rate (100 MHz) and the interpolation rate (4
>> or higher).  No matter what that rate is, your computer should be able to
>> generate samples faster than that.  Since your computer does not have a 100
>> MHz clock to pace the generation of those samples, it will generate them too
>> fast.  When they are sent the USRP2, which can only consume them at a
>> certain rate, they will pile up in the buffers of the USRP2.  Once the
>> buffers get full enough, the USRP2 will send pause frames back to the
>> computer to tell it to wait until the samples it has can work their way
>> through the pipeline.
>>
>> Again, this is completely normal and not because your computer is too slow,
>> and not because the USRP2 is too slow.  It is a normal consequence of the
>> practicalities of generating samples asynchronously to their consumption.
>>
>> So in normal transmit operation, you will see large numbers of pause frames
>> going from the USRP2 to the computer.  Do not be alarmed.
>>
>>
>> When receiving, the USRP only generates data as fast as samples are created
>> by the ADC clock, divided by the decimation rate.  If the decimation rate is
>> 4 then the sample rate is 25 MS/s at 32 bits per sample, or 800 mbits.  This
>> fits just fine into gigabit ethernet, and so it all just goes out almost
>> immediately over the ethernet, and nothing ever backs up and stalls.  If
>> your computer couldn't keep up, then it MIGHT WANT TO send pause frames, but
>> we have disabled that.  Instead, if your computer can't keep up it will drop
>> frames and you'll see "S" in your terminal window.  Get a faster computer or
>> do less processing if you see this.
>>
>> If you were to try a decimation of 3 or lower, then you would be generating
>> more than 1 gigabit per second, and the ethernet wouldn't keep up, and the
>> buffers in the USRP2 would overflow and cause an overrun ("O") error.  You
>> shouldn't be doing this because it won't work.
>>
>> I hope this has cleared it up.  To summarize -- each USRP2 needs its own
>> Gigabit ethernet card to talk to EVEN if it is using only a tiny fraction of
>> the total bandwidth.  And those cards need to be configured to honor flow
>> control.
>>
>> Matt