[Top][All Lists]
[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 08:28:17 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 |
On 03/05/2012 08:10 AM, labarowski wrote:
>
> I'm using an Ettus N210. I have a simple block diagram in GRC with a cosine
> signal source feeding a throttle feeding the usrp sink. All share the
- 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
> samp_rate variable as their sampling rate, which I am trying to get to 50M.
> So far, I've been able to achieve up to 25MSPS using Complex int16 as the
> wire format with minimal under sampling (A few 'U's are printed to the
> terminal at first, but it eventually stabilizes and stops printing Us). I've
> been able to get 33.333333MSPS with minimal undersampling using complex
> int8. I'm yet to achieve 50MSPS. I have an older computer that was unable to
> achieve these sample rates, so I thought it might be my pc. However, this
> laptop has a Core i5 M450 @2.4GHz, 4Gb DDR3 and a gigabit Ethernet card
> (integrated though). I'm not sure how much power gnuradio requires, but I
> feel like this is a fair amount for most applications.
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.
I've set sudo sysctl
> -w net.core.rmem_max=50000000 and sudo sysctl -w net.core.rmem_max=50000000.
rmem max cannot help, this on receive
wmem_max cant make a difference past 1 megabyte. All the buffering is on
the usrp in the transmit direction. wmem_max is simply just large enough
so that any packets going out will have the same amount of space on the
host to guarantee that send() wont block.
> Not sure what else I can do. I thought maybe I could change the decimation
> rate, but that's not going to help if I can't change the format over the
> wire. Any help is appreciated!
Why do you think you cant change the wire format? It sounds like you
changed it to sc8 format (above).
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.
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.
-Josh