discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Understanding USRP2 flow control


From: OE1RSA
Subject: Re: [Discuss-gnuradio] Understanding USRP2 flow control
Date: Fri, 23 Jul 2010 10:35:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Lightning/1.0b1 Thunderbird/3.0.5

Hi Eric,

it took me some time to assemble the RS 232 level shifter.

First to explicitly answer your question about realtime
scheduling. Yes I did put in the explicit enabling you
have told me, and yes, I get no error, i.e. realtime scheduling
should be set succesfully.

2010-07-20 20:18, Blossom:

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

I tried to tune my BIOS settings, but this did not change the
behaviour substantly.

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

Yes, this is how it looks on my machine.

I also experimentally set it to
Autonegotiate: off
RX: off
TX: off

to see, if it would change something, but as you guessed,
it did not improve the situation.

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

I can now confirm that I am seeing bursts of 'UUU...' on the debug
port of the USRP2.

Some more observations:

1) The 6.31 rt kernel from the ubuntu 10.04 LTS is worse than
   the default stock 6.32 kernel.

2) Altough the USRP2 is signaling underuns ( I guess this is what U
   stands for) at the same time I can see in wireshark that I am
   receiving PAUSE frames. This looks like there might be some buffer
   size problems. How large are the transmit buffers of the USRP2?

3) I wrote a small test app that blasts out UDP frames on the same
   interface as fast as it can, and I can see a sustained rate of
   approx 900Mbits/ses. So I guess it is not a limitation of my
   hardware.

Do you have any other ideas what else I could try?

Turning to receive side: I invoked usrp2_fft.py -e eth2 -d 4
and I can see not see 'S' on the terminal. Am I correct in the
assumption this means I have no missed packets on receive?

Thank you for your help!
Roland

-- 
_________________________________________
  _  _  | Roland Schwarz OE1RSA
 |_)(_  | sip:address@hidden
 | \__) | mailto:address@hidden
________| http://www.blackspace.at



reply via email to

[Prev in Thread] Current Thread [Next in Thread]