[Top][All Lists]
[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