discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Question about UHD driver


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Question about UHD driver
Date: Fri, 17 May 2013 11:37:46 -0400
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

Marcus,

I have been running into that issue as well.  It seems that we are in a transition period with the introduction of multi-core processors and OpenCL.  Bus design has not been modified to cope with the parallel duplication of data from high speed serial streams.
The problem is that most hardware that does DMA isn't willing to do so more than once.  You can't tell the USB chip or the Ethernet chip
  "OK, transfer that packet here, and here, and here, and here".  Once the hardware completes a DMA transfer, it moves on, it's done.

The network stack will, necessarily, be not-entirely-zero-copy as well, since it has to deal with network headers, etc, etc.

But the main reason to avoid unnecessary memcopies, is, I think to reduce pressure on the memory bus.  With multi-core CPUs around, it's
  not necessarily the CPU cost that you're concerned about.

Further, any such costs are usually *dwarfed* by the overall cost of the DSP chain.  The cost of getting the samples into the system is a very small
  part of the overall cost of any non-trivial DSP chain.


This has implications for the performance of DSP, as well as other fields, on traditional computing platforms.  It looks like the entire architecture of the PC needs a solid rethink at this point.  As far as I can tell, the current architecture choices are cost related and manufacturers are attempting to software-define all transfers or incorporate SoC solutions.

It means that we are saturating the CPUs with unnecessary tasks and creating bottlenecks as a result.  Until manufacturers start offloading data again, it looks like there will be some hard limits to software defined radio that will make hardware defined solutions more cost effective.
SDR isn't about cost-effectiveness, necessarily.  It's largely about flexibility.  If you have a radio design that is fixed-in-stone, and you're going to produce
  a barjillion of them, you cut an ASIC or two, and you're done.   WiFi chips are cheap, cheap, cheap.

Consider an example.  A wideband FM demodulator chip can be had for a few 10s of cents.  But I can emulate said demodulator on a computer
  with SDR hardware for only a few orders of magnitude more in hardware cost :-) :-)

But if *today* I want to demodulate wideband FM, and tomorrow, I want to do radio astronomy, and the next day, I want to listen to police
  scanners, and the next day, I want to process ionospheric sounder data, an SDR platform may well be the way to go.

Similarly, if I have a "production" RF system of some sort where there will only ever be a small-number (for various values of small-number) deployed,
  an SDR approach may make more economic sense than going down the path of custom hardware design in ASICs, etc.



-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

reply via email to

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