Re: [Discuss-gnuradio] Understanding USRP2 flow control

[Eric Blossom]

On Tue, Jul 20, 2010 at 10:24:51AM +0200, OE1RSA wrote:
> Thank you for your answer.
> 
> Am 2010-07-19 22:06, schrieb Eric Blossom:
> > 
> > Flow control is handled at the link level using ethernet PAUSE frames.
> 
> I was not aware of this ethernet "feature". Having learned
> something new.
> 
> > 
> > Be sure to enable real-time scheduling by calling
> > 
> >     if gr.enable_realtime_scheduling() != gr.RT_OK:
> >         print "Note: failed to enable realtime scheduling, continuing"
> >     
> > before starting or running the flow graph.
> > 
> > If you haven't already, ensure that /etc/security/limits.conf contains
> > this line:
> > 
> > @usrp                -       rtprio          50
> > 
> > and that you are a member of group "usrp".
> 
> Made everyting as told, but still no success.

Just to be clear, do you get the 

  "Note: failed to enable realtime scheduling"

or not.  I'm assuming that you're not seeing this.

> Another observation I have made:
> 
> I am using two kernels from the ubuntu 10.04 LTS distro:
> 
> 2.6.32 generic and
> 2.6.31 rt
> 
> It is interesting that the generic kernel does better than
> the rt kernel. I.e. the rt is practically unusable at
> interpolation 4. The generic does quite well for a while,
> then suddenly drops off.
> 
> Btw.: I am using the e1000e driver for intel cards.
>
> Possibly it may be an issue with the driver?

That driver should be fine.

If your machine has any kind of power control and/or frequency
scaling, be sure that it's configured in its "Performance mode".  That
is, run at full speed all the time, do not try to save energy,
throttle the CPU, etc.

Be sure that flow control is properly configured.
It should look like this with a USRP2 plugged in and powered up:

    $ ethtool -a eth1
    Pause parameters for eth1:
    Autonegotiate:  on
    RX:             on
    TX:             off

> Do you have an idea how I could find out whether my
> problems are because of buffer overrun or underrun?

On transmit, it'll be a buffer underrun.  The host isn't keeping up.

You could hook up a USB CMOS/TTL to serial dongle and watch the diagnostic
output from the USRP2's serial port.

Eric