|
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:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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 complexwell, its 1 thread per block, but grc just generates the flow graph code, its technically out of the loop.
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
earlier.
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"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.
on a general-purpose compute platform. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
[Prev in Thread] | Current Thread | [Next in Thread] |