[USRP-users] overrun 'o' from USRP B210

Ian Buckley ianb at ionconcepts.com
Tue Dec 23 14:16:02 EST 2014


ALT-F,
One interesting little experiment for you. Try running exactly the same application with sample_rate 15.36M and master_clock_rate 30.72M.
It may make no difference what so ever, but in theory it makes the B200 capable of responding a little quicker to available DMA bandwidth to upload data onto the USB3 bus.
-ian

On Dec 23, 2014, at 9:47 AM, Marcus D. Leech via USRP-users <usrp-users at lists.ettus.com> wrote:

> On 12/22/2014 06:20 AM, altaf sk via USRP-users wrote:
>> Hello USRP users,
>> 
>> I am running a flowgraph application (written in C++) with USRP B210 connected to host via USB3.
>> 
>> Sampling rate: 15.36MS/s
>> Master clock rate: 15.36MS/s
>> 
>> using gnuradio 3.7.3 and uhd 3.7.1
>> 
>> I have the overrun 'o' printed on stdout every 3-4 seconds. The signal processing function on the host has heavy computing and I do not want to change the decimation factor.
>> 
>> I tried running the application with high priority but no success.
>> 
>> Is it possible to solve with recv_buff_size parameter.?
>> 
>> Can you please guide me on how to solve this overrun problem.
>> 
>> Regards,
>> 
>> Alt-F
>> 
> Increasing recv_frame_size may or may not help.
> 
> If, on long-term average, your machine cannot "keep up" with the flow, then no amount of buffering will help.
> 
> Also, some USB-3.0 controllers don't handle high-speed flows very well--what type of USB-3.0 controller do you have?
> 
> 
> 
> 
> -- 
> 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





More information about the USRP-users mailing list