[USRP-users] b200 Overflows

Ian Buckley ianb at ionconcepts.com
Mon Sep 29 12:42:57 EDT 2014


Simon, 
Just to give you the H/W picture, you can visualize Rx data in the B200 as flowing through the following in order:
DSP->Packetization Logic-> FIFO's

There actually quite a few FIFO's before the USB interface is reached and they all run (in H/W) much quicker than USB3 throughput.
Thus data "falls through" and tends to accumulate at the last FIFO(s) where it is rate limited by whatever the USB performance is.
If the sustained USB throughput (over a significant period of time) can't match the sample rate (rate over the USB wire...DSP output rate) then that chain of FIFO's slowly fills and, when the packetization logic can not add any more samples to the head of the FIFO chain then and overflow error indication is signaled to the host in an error packet (that bypasses the queued sample data).

Not directly helpful for you I know, but always nice to have the big picture.
-Ian



On Sep 29, 2014, at 12:00 AM, Simon Brown via USRP-users <usrp-users at lists.ettus.com> wrote:

> Marcus,
>  
> 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
> http://v2.sdr-radio.com
>  
> From: Marcus D. Leech [mailto:mleech at ripnet.com] 
> Sent: 27 September 2014 19:41
> To: Simon Brown
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] b200 Overflows
>  
> On 09/27/2014 02:30 PM, Simon Brown via USRP-users wrote:
> Hi Marcus,
>  
> I’ll try sc12 tomorrow, possibly later this evening. I’m currently preparing food and adding some diagnostics.
>  
> It’s probably in the manual, but is there a way to determine the most efficient format for a device without losing resolution, for example sc12 for b200, (maybe) sc16 or fc21 for the N210 etc.? I would like to reduce any network / bus traffic where possible.
>  
> Simon Brown G4ELI
> http://v2.sdr-radio.com
> The number of over-the-wire-formats is strictly-limited---it's not open-ended.
> 
> For all products other than B200, the only available formats are sc16 and sc8.   B200 has the additional sc12 over-the-wire format.
> 
> These "wire formats" are then converted by the driver into one of a few host-side formats, the most natural for a lot of work being
>   fc32.
> 
> The idea behind "wire formats" is to preserve a strictly-limited resource, namely, over-the-wire bandwidth.  No amount of "buying the very best"
>   1GiGe controller, for example, will get you beyond 1Gigabit of bandwidth over that medium.  Which is why to support 50Msps on the N2xx, you
>   have to use 8-bit wire format.    On the B200, you can reduce USB bus bandwidth, but preserve ADC/DAC dynamic range by using SC12.  I think
>   that only really "plays out" (normally) over USB-2.0.  Over USB-3.0, you *should* have plenty of bandwidth available, at least over the USB-3.0
>   bus and inside the controller.   But outside the controller, there may be host-bus limitations that may drive on to using more byte-per-second-conserving
>   formats.
> 
> 
> 
>  
> From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of Marcus D. Leech via USRP-users
> Sent: 27 September 2014 19:11
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] b200 Overflows
>  
> On 09/27/2014 02:00 PM, Simon Brown via USRP-users wrote:
> Thanks,
>  
> I’ve tried changing these, still get overruns with sample rates of 8MS/s or higher.
>  
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>  
> Are you sure that your USB-3.0 interface is actually dealing with the device as a USB-3.0 and not a USB-2.0 device?  
> 
> If you specify a wire-format of sc8 or sc12, do the overruns go away?  This will help distinguish between cases involving CPU exhaustion, and interior
>   bus deficiencies  (I found this on one of my embedded systems--could sustain only 6.4Msps with full-width samples, but was perfectly happy to
>   stream 12.8Msps with 8-bit samples).
> 
> 
> 
> 
> From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of Marcus D. Leech via USRP-users
> Sent: 26 September 2014 20:03
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] b200 Overflows
>  
> On 09/26/2014 02:18 PM, Simon Brown via USRP-users wrote:
> Hi,
>  
> Windows 64-bit: I’m streaming nicely, none of my threads indicate CPU problems (plenty of headroom). At 8MB/s and higher I’m getting fastpath Overrun messages every second or so even though I’m pulling data from the b200 as fast as it’s available, I am not CPU limited in any way. Using Intel USB 3.
>  
> FWIW I don’t see any way to tune the uhd::rx_streamer – bigger / more buffers, also I don’t see any way to flush either.
>  
> Interestingly if I get my CUDA card working harder (more work on the bus) the Overrun messages appear more frequently. I7 4770k, good motherboard (can’t remember what).
>  
> Any suggestions?
>  
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>  
> 
> 
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> The USB transport parameters can be tweaked:
> 
> http://files.ettus.com/manual/page_transport.html#transport_usb_params
> 
> 
> 
> 
>  
>  
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> 
> -- 
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>  
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/79cdcc83/attachment-0002.html>


More information about the USRP-users mailing list