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.
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?
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?
Thanks.
Sebastiaan
–
Sebastiaan H.
Radar and Remote Sensing Group, University of Cape Town, South Africa
Tel: +27 83 305 5667
On Thu, Jun 4, 2009 at 7:20 AM, Sebastiaan H. [email protected]
wrote:
40 of those ‘uO’ s printed on my screen. With a decimation of 32, I
OK
So here I’m also losing 35 samples?
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?
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.
–Andy
On Friday 05 June 2009 05:14:40 Andrew L. wrote:
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.
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