On Fri, Jul 23, 2010 at 10:35:12AM +0200, OE1RSA wrote: > 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.
Roland, all of the stuff below looks good. > > > 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? Sorry, this may have been in an earlier message, but what ethernet chip/card are you using? (lspci will show the details.) We've had lots of problems with RealTek. What kind of CPU are you running on? In my exerience, it takes at least a Core 2 Duo running at 3+ GHz to transmit at full speed. The challenge is that there's not much buffer in the USRP2, and thus the average Tx rate over a very small window needs to be rock solid. If the cpu gets side-tracked doing something else, you'll see underruns. Also, on some machines with multiple CPU sockets, such as my dual quad core Xeon, on some versions of the OS, it really matters as to whether or not all of the computation is running on a single physical chip. If you've got a machine like that, try using numactl to force all the threads to live on a single physical chip (not core). If you look at the output of cat /proc/cpuinfo, "physical id" indicates which cores are in which sockets. (How the processors are assigned numbers seems to have a random component (at least under some versions of the OS)) > 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? Yes. > Thank you for your help! You're welcome. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
