Re: [Discuss-gnuradio] Question about the USB of USRP1

[Stefan Brüns]

On Friday 05 June 2009 05:14:40 Andrew Lutomirski wrote:
> On Thu, Jun 4, 2009 at 7:20 AM, Sebastiaan Heunis <address@hidden> wrote:
> > Hi all
> >
> > I've got a question about the bandwidth that the USRP1 can support
> > across the USB.  We have 32MB/s across the USB corresponding to 8Msps
> > for a single I-Q stream.  When we have two I-Q streams, this becomes
> > 4Msps for each stream.
> >
> > This means that when I have two I-Q sampled channels, I should be able
> > to set the decimation for each channel to 16.  This does however not
> > work.  With two I-Q channels, if I set decimation to 16, I get about
> > 40 of those 'uO' s printed on my screen.  With a decimation of 32, I
> > get about 4.  With a decimation of 64, I get none.  So, currently I am
> > only able to support 8MB/s accross my USB without losing any samples.

Keep in mind there is no direct relation between number of reported Overruns 
and the number of dropped samples, as the usrp is only polled for overruns at 
a fixed interval. Still the general figure of increased number of overruns 
for low dec rate stands.

> > I ran the usrp_benchmark_usb.py and got the following:
> >
> > Testing 32MB/sec... usb_throughput = 32M
> > ntotal    = 16000000
> > nright    = 15999965
> > runlength = 15999965
> > delta     = 35
> > OK
> >
> > So here I'm also losing 35 samples?
> >

This is expected behaviour (more or less). The first sample sent to the USRP 
may be received different to the first received sample, i.e there is some 
misalignment. The only important figure is the runlength, if it is 
sufficiently large, no sample has been dropped during the test run.

> > I have an HP Pavilion dv6500 laptop with a 1.5GHz Core2Duo CPU and 2GB
> > of RAM.  I'm also using a CPU frequency scaling utility to make sure
> > that my PC is running at full blast.  Might it be that the USB
> > controllers of laptops aren't that great, or is it normal to lose some
> > samples at 32MBps?

Disk access, some video card drivers may be keeping the kernel from 
rescheduling for quite some time. The guys using Linux for audio recording 
have some more information for sure, try googling ...

> I have 12 USRPs running at a decimation of 16 with 2 I/Q channels.  On
> the current run, I've collected 2 *trillion* samples on each without
> any overruns.  I'm doing this on Celeron 220's, which makes your
> laptop look positively fast.
>
> I'd check if you have realtime scheduling enabled and maybe try with
> C++ code instead of Python -- I've had good luck with
> usrp/host/apps/test_usrp_standard_rx.cc, although I haven't had much
> trouble with the Python code either.

Realtime scheduling makes a very big difference if you have sporadic drops. 
There should be no difference between C++ and Python code, as the signal 
processing is done by the C++ code always.

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
mailto:lurch at gmx.li  http://www.kawo1.rwth-aachen.de/~lurchi/
   phone: +49 241 53809034     mobile: +49 151 50412019