|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Rx overflow with high sample rate and high CPU utilization |
Date: | Thu, 7 Apr 2016 14:08:23 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
Dear SangHyuk, please be aware that digital receivers aren't really easy to make more CPU efficient; a real-world receiver not only has to convert received symbols to bits, but has to do the frequency and frame synchronization as well as a timing recovery; high-bandwidth transceivers must go through significant amounts of equalization (OFDM is one way to approach this, converting one giant channel into a lot of narrow, hence, nearly flat, channels that can be single-tap equalized, at the expense of doing FFTs and inserting pilots/redundancy), too. The Benchmark_* tools aren't really doing anything to equalize (if I remember correctly), so they aren't really applicable to wideband channels, and if you do equalization, you'll probably be even slower. As said on numerous occassions, go ahead and try the rx_ofdm.grc and tx_ofdm.grc examples from gr-digital. They are much more modern. If I had a diagnosis, still, your PC is probably simply too slow for receivers that aren't highly optimized; GNU Radio really does its best with efficient filter, FFT, synchronizer structures, but it might not be able to compensate that at 2.7GHz x 4 cores, you only have 432 CPU cycles per sample at 25MS/s, if your application was perfectly scalable (which it's not). That's not really much for a complicated receiver, if you consider that includes all the data handling (ie. getting data from the network card, converting it to something your CPU can deal with, writing the results somewhere), filtering, synchronization, channelizing (if doing *FDM), symbol decision, de-framing, channel decoding (no one would build a real-world transceiver without that), and as said, benchmark_rx (from the gr-digital/examples/ofdm directory, we're not talking about the narrowband one) isn't that optimally structured – it's really just a proof of concept. Best regards, Marcus On 07.04.2016 13:39, SangHyuk Kim
wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |