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
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:
Yes, this is how it looks on my machine.
I also experimentally set it to
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:
The 6.31 rt kernel from the ubuntu 10.04 LTS is worse than
the default stock 6.32 kernel.
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?
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
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 Schwarz OE1RSA
|)( | sip:[email protected]
| __) | mailto:[email protected]