[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:



> 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.


reply via email to

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