[Top][All Lists]

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

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

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Cannot Achieve 50MSPS Sampling Rate
Date: Mon, 05 Mar 2012 18:43:26 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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

The unspoken text here is that Gnu Radio has two different scheduling "policies" for a flow-graph--the default for several years had been TPB (Thread-Per-Block). Which improves your odds of "keeping up" with complex
  flow-graphs across many blocks.

But individual blocks don't, as a rule, perform operations across multiple threads. There are exceptions--the FFT blocks now provide the *option* of doing their work across multiple threads. But that's only worthwhile for very large FFT operations--20K bins or so or larger. Computer science hasn't yet come up with any general-purpose way of converting serial algorithms into parallel ones that are *unconditionally better* that their serial counterparts. So most of the blocks in Gnu Radio are essentially serial in nature, with occasional optimizations like the SIMD optimizations described

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.

There's no support for anything other than 16-bit or 8-bit (I and Q) samples on the wire. In some wide-band applications, like radio astronomy, using fewer bits to gain bandwidth is pretty commonplace. But in general-purpose SDR platforms, not so much. But more importantly, handling 50Msps and *doing anything useful* present significant challenges if you want to "do those things"
  on a general-purpose compute platform.

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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