discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Cannot Achieve 50MSPS Sampling Rate


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Cannot Achieve 50MSPS Sampling Rate
Date: Mon, 05 Mar 2012 14:46:27 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0


On 03/05/2012 01:58 PM, labarowski wrote:
> 
> 
> Josh Blum-3 wrote:
>>
>>
>>> - dont use a throttle, the usrp sink *is* back-pressuring the stream
>>
>>> - use this new signal source on my new_blocks or next branch, its much
>>> much faster:
>>
>>> git://gnuradio.org/jblum.git
>>
>>> http://gnuradio.org/cgit/jblum.git/tree/gr-blocks/lib/signal_source.cc?h=new_blocks
>>
>> Didn't realize that a throttle was unnecessary with the usrp. Thanks for
>> pointing that out. I see that you have a lot of other blocks in your
>> repository as well. Do these have any advantage to the ones included with
>> gnuradio?
>>
>>

They all add performance, utility, also support for fixed point IO.

>>
>>> 50 Msps is serious amount of data to push through your computer. More
>>> than a feeling, even the most serious computers can easily have a
>>> bottleneck. I suspect that the gnuradio core signal source cannot
>>> sustain 50Msps in 1 thread/1 work function.
>>
>> Makes sense. I would assume that, as long as I'm using grc at least, I'm
>> limited to one thread?
>>

well, its 1 thread per block, but grc just generates the flow graph
code, its technically out of the loop.

>>> Why do you think you cant change the wire format? It sounds like you
>>> changed it to sc8 format (above).
>> Should have worded that more carefully. I can choose 8 or 16 bits over the
>> wire. My thinking was that I might be able to increase the rate of
>> decimation (on second thought, decimation has more to do with sampling
>> frequency than a data bottleneck) and also decrease the precision and use
>> an integer less than 8bits. Basically, I thought ethernet may have been
>> the bottleneck. Decreasing precision shouldn't be necessary, I'm just
>> trying to build an understanding here.
>>

ok cool

>>> I prototyping whatever it is you are trying to do at a lower rate, then
>>> optimizing it in SIMD routines to get up to 50 Msps on the host.
>> I was totally unaware of SIMD before you mentioned it. That's an
>> interesting subject. It is my understand that SIMD is integrated into
>> gnuradio through VOLK as of Dec. 2010. Doesn't look like I can use VOLK
>> directely from grc, or even from Python. Looks like it needs to be
>> implemented at the block level in C++. Is this the case?
>>
>>> Also, try examples/tx_waveforms with --otw=sc8 --rate=50e6 and
>>> experiment with that so you can see if your PC can sustain the rate with
>>> minimal load.
>>
>> I actually couldn't find that in my /usr/local/share/gnuradio/examples
>> folder. Do I need to download it elsewhere?
>>

<installprefix>/share/uhd/examples/tx_waveforms

or in your build directory of uhd

<builddir>/examples/tx_waveforms

> Thanks for the informative post Josh! 50MSPS will probably prove unnecessary
> for the project that I'm working on. I was worried that perhaps I was doing
> something fundamentally wrong and that's why  I wasn't getting the full
> sampling rate out of this device.

Thanks!
-Josh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]