Re: [Discuss-gnuradio] Understanding flow control

[Tom Gross]

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...

have a good weekend!
-Tom


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
>