On 03/08/2013 02:44 PM, Tom Hendrick wrote:
> Hi Josh,
> 
> Would you happen to suggest any more setting changes I could try before just 
> deciding I need to depend on the older libusrp/gnuradio for recording 4 
> channels to disk from a USRP?

On this particular machine, are you able to sustain one channel at 8Msps
but not 4 channels at 2Msps? That might indicate that there isnt enough
headroom for the deinterleaving. The old driver just output interleaved
data, and you would deinterleave samples in a separate block.

-josh

> Thanks, - Tom
> 
> 
> 
> 
> 
> ________________________________
>  From: Josh Blum <j...@ettus.com>
> To: Tom Hendrick <sdtom...@yahoo.com> 
> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> 
> Sent: Saturday, March 2, 2013 9:18 AM
> Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older 
> machines
>  
> 
> 
> On 03/01/2013 05:16 PM, Tom Hendrick wrote:
>> Josh,
>>
>> Thank you so much for the suggestion. I will try this.  I have 4GB of
>> ram and a 4GB swapfile size.  Do you recommend any particular setting
>> for set_max_output_buffer(long max_output_buffer)?
>>
>>
> 
> Make it 10s of megabytes, see if it helps.
> 
>> Should I leave tb.run() as is, or modify the number of n_output_items
>> in conjunction with the
> 
> I think that part of the API is deprecated (the argument to run). There
> is a similar call on top block, but Im recommending just the usrp source
> block.
> 
>>
>> void set_max_output_buffer(long max_output_buffer)?
>>
>>
>> Also, do you recommend any particular settings using uhd_usrp_probe
>> --args="serial=123456, recv_frame_size=XXXX,num_recv_frames=XXXX",
>> send_frame_size=XXXX,send_recv_frames=XXX"
>>
>>
>> or should I leave it default?  The custom 4 channel usrp block in the
>> older gnuradio version had the fusb_block and  fusb_nblocks both set
>> to 512*32
>>
> 
> Go with the default while trying the above.
> 
> -josh
> 
>> Thanks, -Tom
>>
>>
>>
>>
>> ________________________________ From: Josh Blum <j...@ettus.com> To:
>> discuss-gnuradio@gnu.org Sent: Friday, March 1, 2013 2:55 PM Subject:
>> Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
>> machines
>>
>>
>>
>> On 03/01/2013 04:51 PM, Tom Hendrick wrote:
>>> Hello all,
>>>
>>> I've had trouble making a 4 channel USRP samples at 1Ms/s write to
>>> file at 500 kS/s with ubuntu 12.04 and libuhd.  I am getting
>>> several overruns and I had tried adjusting some of the parameters
>>> using usrd_probe_devices but with no success. I have a laptop with
>>> a duo core centrino processor which should be enough.
>>>
>>> I've made this 4 channel work successfully with the same exact
>>> laptop and with ubuntu 10.04 and the older version of gnuradio that
>>> uses libusrp.  I get no underruns at all even for an entire hour of
>>> writing to file.
>>>
>>>
>>> Has anyone else experienced performance differences between libusrp
>>> and libuhd?  I just want to make sure it isn't a configuration
>>> problem or something I'm doing wrong causing the overruns.  If its
>>> likely an issue with libuhd, I guess I will just keep a backup of
>>> ubuntu 10.04 and gnuradio libusrp version installation files and
>>> leave my dual boot setup intact.
>>>
>>> Thank you very much, - Tom
>>>
>>>
>>
>> You might try setting a very large output buffer on the usrp source 
>> block. I heard this helps (you should be able to call this in python 
>> after the block constructs):
>>
>> /*! * \brief Sets max buffer size on all output ports. */ void
>> set_max_output_buffer(long max_output_buffer)
>>
>> -josh
>>
>>>
>>> _______________________________________________ Discuss-gnuradio
>>> mailing list Discuss-gnuradio@gnu.org 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> _______________________________________________ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to