A Peek at GNU Radio’s Buffer Architecture
gnuradio.org
A Peek at GNU Radio’s Buffer Architecture
1–10 of 16 posts
Re: A Peek at GNU Radio’s Buffer Architecture
#2The double-mapped ring buffer trick is so clever I can't help but wish I invented it. :)
Here's the code for the GNU radio implementation described in the article, it's a good reference for some various ways to set up the mappings:
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-ru... https://github.com/gnuradio/gnuradio/blob/master/gnuradio-ru... https://github.com/gnuradio/gnuradio/blob/master/gnuradio-ru...
And here some other links to implementations I've collected:
https://fgiesen.wordpress.com/2012/07/21/the-magic-ring-buff... https://gist.github.com/rygorous/3158316
https://www.mikeash.com/pyblog/friday-qa-2012-02-03-ring-buf... https://www.mikeash.com/pyblog/friday-qa-2012-02-17-ring-buf... https://github.com/mikeash/MAMirroredQueue
http://atastypixel.com/blog/a-simple-fast-circular-buffer-im... https://github.com/michaeltyson/TPCircularBuffer
http://www.koanlogic.com/libu/api/html/group__rb.html
https://github.com/ulfalizer/botniklas/blob/master/src/read_...
Re: A Peek at GNU Radio’s Buffer Architecture
#3SDR strikes me as good in theory, but breaks down for anything practical.
My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
Re: A Peek at GNU Radio’s Buffer Architecture
#4SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
Any other prefiltering / post-processing? This processing should be pretty trivial on its own. This should be fairly easy load - definitely not pegging the CPU at 100%.
Re: A Peek at GNU Radio’s Buffer Architecture
#5SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
You may find this SDR LTE eNodeB interesting: http://bellard.org/lte/
There's also this open-source LTE library: https://github.com/srsLTE/srsLTE
Re: A Peek at GNU Radio’s Buffer Architecture
#6SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
SIMD is only going to get you so far; I'd expect much greater gains from running on a GPU.
Re: A Peek at GNU Radio’s Buffer Architecture
#7SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
I run a HackRF One on an i7 (Intel NUC) and it is hard to peg the Cores. Typically when I do it is because some synthetic workload is dumping infinite work into the buffers and so everything is running full on, but generally real signals have been 20 - 30% of one or two cores.
Re: A Peek at GNU Radio’s Buffer Architecture
#8SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
Something's terribly wrong with your flowgraph.
Re: A Peek at GNU Radio’s Buffer Architecture
#9SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
Core 2 duo was released in 2006, is it as bad on anything from this decade?
Re: A Peek at GNU Radio’s Buffer Architecture
#10SDR strikes me as good in theory, but breaks down for anything practical. My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).
It is practical, but it's important to have the core of your code optimised. In particular, you will need a very tight "multiply-accumulate" loop, as typically used in an FIR filter.
By way of real-world example, a 9600 bps P25 transceiver (with FEC) can be done on a C5500 DSP (200MHz) with about 10-20% CPU utilisation. As a further illustration, a vocoder that could not run in real-time was reduced to 5% CPU usage when a correlator (a single MAC loop in C) was replaced with the equivalent assembly that used a MAC instruction. 97% of the CPU time was being spent in that loop.