On 02/13/2018 04:52 AM, Kasper Føns via USRP-users wrote:
Hi.
We have bought a B200 board and are having issues simply receiving the
samples and would like some support in the matter.
Running the command
./rx_samples_to_file --null --rate 56000000
on a Sony Vaio Z with an I5-3210M running Ubuntu Server 17.10 shows a
high CPU usage of ~78%.
Is such a high CPU usage expected?
Switching terminal windows (ALT + F1 or ALT + F2) is enough to cause an
overflow on the Linux host.
There is also a high CPU usage on a Windows 10 machine (ThinkPad,
i7-4810MQ).
Running
./rx_samples_to_file --null --rate 56000000
results in a infinite stream of overflows.
Running
./rx_samples_to_file --null --rate 32000000
utilizes 22% CPU and still overflows once in a while. Moving a
calculator window around the screen results in overflows.
We have tried increasing buffers using --args="recv_frame_size=X,
num_recv_frames=Y"
However, we haven't been able to increase X to higher values than ~16000
(16384 fails with lots of overflows).
The same applies to Y, where 300 fails with an error.
The software was compiled in release mode an ran over a USB 3 connection.
Thus, for USB transfers using the B200:
- On Vaio: Is ~78% CPU usage expected for 56 Msps ?
- On Win10: Is it not possible to receive 56 Msps?
- On Win10: Is 22% CPU usage expected for 32 Msps?
- Is there some limit to recv_frame_size? A value of 16384 fails with
infinite overflows.
- Is there some way of tuning the framework for lower CPU?
W_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
e hope you are able to help!
Let's do some first-order math.
You're bringing in ~5e7 samples/second
If we optimistically assume a mean instructions-per-sample (including
both kernel and user-space code) of 100 instructions/sample, then we're
talking a
requirement for 5e9 instructions/second. If your CPU is running at
3e9 Hz, then it'll need to, on average, issue 1.6 instructions/cycle.
You'll generally get more "mileage" out of num_recv_frames than the
frame size. On any given system, my understanding is that this is a
shared resource
(across a given USB controller, I think, but don't quote me).
Now, the rx_samples_to_file application is single-threaded, so it's
trying to service the data-stream from the USRP at the same time as it's
making filesystem
calls to write the data (even if to /dev/null). That's a tall order
for a single-threaded application running at 5.6e7sps. These
applications, provided with
UHD, are generally intended as *coding examples*, and no guarantees
exist with respect to performance on any given system. Furthermore, some
USB3 controllers are better at handling bulk high-data-rate
applications than others, and the controller landscape changes so
quickly that it's next to
impossible to provide up-to-date recommendations in that department.
If you install Gnu Radio, there's an application called "uhd_rx_cfile"
that takes advantage of the multi-threaded nature of Gnu Radio, and does
better.
But keep *firmly in mind* that once you migrate from writing to
/dev/null to writing to real disk hardware, 5e7 samples/second is going
to result in
a LOT of disk I/O--more than most ordinary single-disk, non-RAID disk
systems can usefully sustain.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
