On 02/13/2018 04:52 AM, Kasper Føns via USRP-users wrote:

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,
   ./rx_samples_to_file --null --rate 56000000
results in a infinite stream of overflows.

   ./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,
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?

USRP-users mailing list

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

Reply via email to