[USRP-users] Help improving USRP B200 throughput
jpheym at gmail.com
Sun Sep 7 23:30:20 EDT 2014
Thank you for time and assistance.
By percent reliability I mean number of txrx_loopback_to_file commands
that succeeded without any underflow errors. The command line I used
is listed at the top of that spreadsheet I attached to my first
message. I now realize this is a somewhat less informative way of
testing versus benchmark_rate.
CPU usage by txrx_loopback_to_file is about 50% of one core on an 8
core Intel Core i7 CPU. "benchmark_rate --tx_rate 16000000" uses 24%
of one core. All other cores are idle. And the computer is generally
idle (minimal programs running). CPU usage does not seem to be an
Yes I tried one other machine. It has an older NEC USB 3.0 controller
(not a great one) and showed similar results. I would like to try a
third machine or perhaps purchase a USB 3.0 adapter once I figure out
which USB 3.0 host controller chipset is most compatible with the USRP
B200. It is also possible I have a defective B200 board.
Yes I just tried benchmark_rate. 4 trials per rate, transmit and
receive. Summary of results:
Num underflows detected for "benchmark_rate --tx_rate <rate>":
rate = 4000000: 0 0 0 0
rate = 8000000: 0 1 0 0
rate = 16000000: 1 1 5 0
rate = 32000000: 7 11 10 2
Num underflows detected for "benchmark_rate --rx_rate <rate>":
rate = 1000000: 0 <error> 0 0
rate = 2000000: <always error>
rate = 4000000: <always error>
rate = 8000000: <always error>
The errors seen in the receive benchmark tests are:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
Receiver error: ERROR_CODE_BAD_PACKET
Unexpected error on recv, continuing...
(the above text repeated over 100 times)
terminate called after throwing an instance of 'uhd::runtime_error'
what(): RuntimeError: usb tx4 submit failed: LIBUSB_ERROR_CODE -4
Aborted (core dumped)
I saw a similar pattern with txrx_loopback_to_file. Receive is much
On Sun, Sep 7, 2014 at 4:52 AM, Martin Braun via USRP-users
<usrp-users at lists.ettus.com> wrote:
> Hey Jason,
> sorry for not giving you an answer sooner. As you already pointed out,
> USB3 high rate operations is still a bit wonky in general; with USRPs,
> you don't only need to be able to sustain high rates, but also to keep
> them up reliably without backing up.
> Four questions:
> - What exactly do you mean by x% reliability?
> - What's your CPU usage during ops?
> - Have you tried benchmark_rate to see if your app has an influence?
> - Have you tried other machines for testing purposes, see if other USB
> chipsets or hardware matter?
> On 09/04/2014 10:57 PM, Jason Heym via USRP-users wrote:
>> Bumping this thread...
>> Any suggestions?
>> On Fri, Aug 29, 2014 at 6:47 PM, Jason Heym <jpheym at gmail.com> wrote:
>>> I have been testing a recently-purchased USRP B200 with an Asus G750 laptop.
>>> My goal is full duplex 32 million samples/second TX and RX.
>>> Reliability is very important. This is for some radar experiments that
>>> need maximum TX and RX bandwidth continuously for periods of several
>>> Please see the attached test results.
>>> Note I'm doing TX and RX of 50M samples for each run. So each run
>>> represents a few seconds of TX and RX. Fewer samples per run will have
>>> less chance of interruption and produce higher success rates. But my
>>> goal is interruption-free operation over at least a few minutes.
>>> Basically for 2 to 8 MSPS symmetric (TX and RX) reliability is around
>>> 50% to 60%. At 16 MSPS reliability drops to 25%. At 32 MSPS there is
>>> total failure. Reducing the RX data rate while keeping the TX rate
>>> fixed can improve success rates. However the opposite (reducing TX
>>> data rate and keeping RX fixed) does not help. I do need symmetric
>>> data rates.
>>> What can I do to improve the throughput or better diagnose and address
>>> the problem?
>>> I prefer a laptop for portable / field operation. This laptop performs
>>> well with a Point Grey Grasshopper3 USB 3.0 camera, achieving 350
>>> MB/second error-free for extended periods (a few hours). Obviously
>>> this is mostly camera-to-host throughput, not symmetric full duplex.
>>> The B200 and AD9361 have enormous potential. I just need to improve
>>> the throughput situation. I recognize that USB 3.0 SuperSpeed has its
>>> challenges, probably especially for full-duplex symmetric throughput.
>>> Thank you!
>>> Jason Heym
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
More information about the USRP-users