[Discuss-gnuradio] USB + USRP performance on Mac OS X

[Jonathan Jacky]

I built usrp and gr-usrp on Mac OS X, with some help from Michael
Dickens. I linked with libusb from darwinports and IOKit from OS X
itself.  I have not made any changes to the fusb files in
usrp/host/lib -- this is unmodified GNU Radio straight from CVS
(checked out Nov 28 2005).

I observed the performance of several GNU Radio programs on two
hardware configurations: a dual 2.7 GHz PowerPC G5 with built-in USB
2.0, and a 1 GHz Powerbook G4 with the Belkin F5U222 USB 2.0 card
(this Powerbook only has USB 1.1 built-in).  On both I ran Mac OS X
10.4.3, with a USRP Rev 2 with Standard TX and Standard RX
daughterboards.

I was pleased to find that, with the present USB support, GNU Radio
can transfer at up to 4 MB/sec between the Mac host and the USRP (this
confirms Michael Dickens' experience).  This means that the software
in its present condition can transfer audio frequency signals between
the Mac host and the USRP, which should be sufficient for much of our
MRFM work.

Running test_usrp_standard_tx -I 128 (interpolation factor 128) on the
G5 (with build in USB 2.0) reports no underruns and 4e+06 bytes/sec.
At this same -I 128, the G4 (with the Belkin card) reports 12
underruns around startup and 3.992+e06 bytes/sec; -I 256 and -I 512
results in 11 and 5 underruns, respectively.  Running a version with
the statements that print "tx_underrun" commented out reports the same
results.  The TX-A output viewed on an oscilloscope (a real one) is a
clean sine wave. Running on both machines with interpolation less than
128 results in many underruns throughought the run, and the scope
shows flatlines alternating with the sinewave.

Running usrp_siggen.py -i128 on the G5 results in no uUuUuU... output
and the scope shows a sine wave.  -i64 and smaller produces a stream
of uUuUuU... output (indicating underruns) and some
flatlines interrupting the sine wave.  On the G4 + Belkin card, -i256
is the smallest interpolation that doesn't produce underruns.

Running usrp_oscope -g0 -f0 -d64 (decimation 64) on the G5 results in
just a few uOuOuO indicating overruns at startup.  When a sine wave
from a signal generator is connected to RX-A, the usrp_oscope display
shows an uninterrupted sine wave.  At smaller decimation,
uOuO... appear continually and the display shows some discontinuous
jumps.  On the G4 + Belkin card, -d128 is the smallest decimation that
does not result in continual uOuOuO...  At this decimation the
sampling frequency is 500 KHz.  The 50 KHz sine wave from the signal
generator is displayed at 10 samples/cycle without much distortion and
20 KHz looks very smooth.

Likewise, usrp_fft -d64 on the G5 results in just a few uOuO at
startup, and so does -d128 on the G4 + Belkin card.

I tried usrp_siggen and usrp_oscope (or usrp_fft) at the same time on the
G4 + Belkin, with TX-A connected to RX-A.  With usrp_oscope -d256 and
usrp_siggen -i512 I get no uOuO from scope and no uUuUuU from siggen.
That's a sampling frequency of 250 KHz, so the scope display looks
satisfactory on frequencies below 20 KHz.

Jon Jacky

PS. At startup all programs always complain "usb_control_message failed
... pipe is stalled" even when there are no underruns or overruns.
For example:

% ./usrp_siggen.py -i128
TX d'board A: Basic Tx
usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled
TX d'board B: <none>
Press Enter to quit:

PPS.  In my installation, benchmark_usb always aborts with a failed assertion
before reporting results:

% ./benchmark_usb.py
Testing 2MB/sec... TX d'board A: Basic Tx
usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled
TX d'board B: <none>
RX d'board A: Basic Rx
usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled
RX d'board B: <none>
usrp1_sink_base.cc:123: failed assertion `obi % 512 == 0'
Abort