Re: [Discuss-gnuradio] Question about UHD driver

[Mark McCarron]

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.

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.

Regards,

Mark McCarron

> Date: Fri, 17 May 2013 16:53:07 +0200
> From: address@hidden
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Question about UHD driver
>
> Hi Mark,
>
> for currently available UHD devices with high bandwidth, data comes into
> the host computer via a gigabit ethernet controller (or USB).
> UHD basically talks to the kernel and uses the data provided by the
> network card driver/network stack; therefore, UHD specifies a layer
> built upon hardware drivers, it does not copy the data from the NIC itself.
> (Same applies for USB controllers)
> So unless you start rewriting Gigabit Ethernet card hardware drivers,
> there's no way to get the same hardware data into the host system via
> multiple DMA calls with the same origin.
>
> Greetings,
> Marcus
>
> Am 17.05.2013 06:40, schrieb Mark McCarron:
> > Matt,
> >
> > My area of research is DSP and massive parallelism. Given the structure
> > of GNU Radio, it is possible to know what data is required upfront.
> > This opens up the possibility of a performance boost. I know how
> > GNURadio works, it was discussed earlier when I raised this question.
> >
> > There is a different way though. Lets assume we have two branches
> > coming from the source. The first is going to an FFT, the second to
> > some form of flow-graph that performs functions on the IQ stream. Also,
> > we don't want the changes we make to the IQ stream to be reflected in
> > the FFT.
> >
> > Now, we can approach this several ways:
> >
> > 1. Serial - Send the data first to FFT, then to the second portion of
> > the flow-graph.
> > 2. Parallel (memcopy) - Copy the data in memory, provide one to the FFT
> > and the other to the IQ flow-graph.
> > 3. Parallel (DMA/Driver) - Driver duplicates the data in memory
> > according to the needs of the program. This is not a memcopy, but a
> > true parallel creation as the stream is extracted from the wire.
> >
> > The last approach allows us to lighten the load on the application and
> > CPU by off-loading initial memory allocation to DMA controllers. This
> > way, we don't need to manage FIFO streams within the app in relation to
> > the initial input.
> >
> > As I said, I am still checking if this is possible, but when working
> > with multiple branches that require independent copies of the data this
> > would be best performing way to deliver the data.
> >
> > Regards,
> >
> > Mark McCarron
> >
> > ------------------------------------------------------------------------
> > From: address@hidden
> > Date: Thu, 16 May 2013 21:11:42 -0700
> > Subject: Re: [Discuss-gnuradio] Question about UHD driver
> > To: address@hidden
> > CC: address@hidden
> >
> >
> > Are you saying that it is better to always make copies of the data
> > rather than just make copies when you need them?
> >
> > In any case, I think you misunderstand both how GNU Radio works and how
> > UHD interacts with it. UHD provides a single copy of data to GNU Radio
> > for two reasons -- first, that is the most efficient thing to do, and
> > second, UHD can't possibly know what GNU Radio plans to do with the
> > data. GNU Radio passes pointers of the data to every block that needs
> > it. Blocks are not allowed to modify their inputs, only their outputs.
> > This is fundamental to how GNU Radio operates.
> >
> > Matt
> >
> >
> >
> >
> > On Thu, May 16, 2013 at 9:02 PM, Mark McCarron <address@hidden
> > <mailto:address@hidden>> wrote:
> >
> > There is a performance issue with this. If your program needs to
> > manipulate the raw data, but at the same time provide that raw data
> > to another branch(es), a copy much be made. If this is the case,
> > then it would make more sense to duplicate the data in parallel as
> > it enters the system. This should be more efficient than memcopy.
> >
> > I am looking into DMA to see if this is possible.
> >
> > Regards,
> >
> > Mark McCarron
> >
> > ------------------------------------------------------------------------
> > From: address@hidden <mailto:address@hidden>
> > Date: Thu, 16 May 2013 20:51:32 -0700
> > Subject: Re: [Discuss-gnuradio] Question about UHD driver
> > To: address@hidden <mailto:address@hidden>
> > CC: address@hidden <mailto:address@hidden>
> >
> >
> >
> > There is no need to create multiple copies. The consuming blocks
> > are each given a pointer to the same data, and the memory is not
> > freed until all the consuming blocks indicate they are done with it.
> >
> > Matt
> >
> >
> > On Thu, May 16, 2013 at 11:00 AM, Mark McCarron
> > <address@hidden <mailto:address@hidden>> wrote:
> >
> > I am wondering if the UHD driver has the ability to create
> > multiple copies of the stream in memory???
> >
> > Let's say I have a flow-graph that has two branches, the first
> > pushes complex data to an FFT, whereas the second demodulates a
> > portion of that data into AM.
> >
> > Does the driver supply a single stream, which is then copied by
> > the application? Or does it create two copies of the stream and
> > allow each branch of the flow-graph to manipulate the data via
> > pointers?
> >
> > I'm digging into DMA to see if this is possible, I would be
> > surprised if there was a limitation here.
> >
> > Regards,
> >
> > Mark McCarron
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden <mailto:address@hidden>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden <mailto:address@hidden>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio