[USRP-users] b200 Overflows
Marcus D. Leech
mleech at ripnet.com
Mon Sep 29 10:14:39 EDT 2014
On 09/29/2014 10:04 AM, Marcus D. Leech via USRP-users wrote:
> On 09/29/2014 03:00 AM, Simon Brown wrote:
>> Using the 007.003.001 codebase uhd::stream_args_t("sc16", "sc12")
>> crashes inside usrp->get_rx_stream. I don't see any reference to sc12
>> in the https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so
>> I'm a bit lost now.
>> Please clarify (I've read the source) if I get an overrun then the
>> data is being delivered from the B200 faster than the UHD.dll is
>> reading it? If this is the case I also believe that there's no way I
>> can tell the underlying code to flush the LibUSB buffers?
>> I'm currently having considerable success with all Ettus hardware
>> flavours but am a tad stuck with the whole UHD concept / way of life,
>> your help is greatly appreciated.
>> Simon Brown G4ELI
> Describes the components of stream_args_t. In particular, the first
> component is the desired host-side ("CPU") format, the second the
> I think sc12 was introduced after UHD 3.7.1, so upgrade.
Actually, I somewhat mis-spoke. As of current release, there is no
converter from sc12 to sc16, only to fc32, so if you use sc12
pretty-much have to use fc32, and then if desired, convert it
yourself to an integer format.
Some DSP folks have an aversion to floating-point for DSP work, but in
fact on "ordinary" machines, notably, x86, floating-point is very often the
better format for heavy-duty numerical work, both because of the heavy
pipelining of non-SIMD floating point, and because of the SIMD units
that can be used aggressively to handle floating-point numerical
streams. There are exceptions, of course, where the integer ALU is
there's generally much more "pressure" on the integer unit from
ordinary, non-numerical, flows.
There is no "flush the USB buffers, please" API call. The overall
reason for overruns is that the hardware is delivering them faster than your
system, overall, can cope. The "harvester" of data in UHD is quite
efficient, so if things are running into trouble, it's usually the
that is the cause. There's usually no single cause, but a
collection of things all cooperating to hamper your ability to handle
real-time data flows.
The benchmark_rate tool that I mentioned last week can be used to get
some rough idea of what the basic "stack" from USB up to UHD can handle,
without bringing in the complexity of actually "doing stuff" with the
Shirleys Bay Radio Astronomy Consortium
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users