|
From: | Mark McCarron |
Subject: | Re: [Discuss-gnuradio] Question about UHD driver |
Date: | Fri, 17 May 2013 17:34:41 +0100 |
I would tend to agree, but if we do not outline what we require from manufacturers, we will never get it. I would seriously suggest writing a specification and submitting it to Intel, AMD, etc.
Regards, Mark McCarron > Date: Fri, 17 May 2013 18:04:37 +0200 > From: address@hidden > To: address@hidden > Subject: Re: [Discuss-gnuradio] Question about UHD driver > > Hi Mark, > > as interesting as your point is, that's not something that > can be fixed within the scope of GNU Radio or even UHD... > > Anyhow, I'm not really convinced that multiple DMA transfers are always > faster than copying data using memcpy - at least if those DMA transfers > copy only a few kilobytes, as is the case with packets from network devices. > The fact that packets are of limited size is not really a problem of > current computing architectures - it's a consequence of having packet > networks. Of course, it would be nice if your hardware would be able to > actually stream data into your userland, that somehow has the (zero > overhead) capability to tell the hardware to send the next sample - but > in reality, hardware-to-cpu-transfers usually happen en block, and that > is just fine for most applications, since there is little use of having > samples one after another; therefore, some buffering is always necessary > (and will always be). > For the sake of adaptivity, hardware supplied data most probably won't > be written to copy device data to multiple RAM addresses, since the data > from the device usually needs some processing (hence the driver). > So in effect, in most imaginable cases a device will do a single > DMA transfer to RAM. > > Greetings, > Marcus > > _______________________________________________ > Discuss-gnuradio mailing list > address@hidden > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio |
[Prev in Thread] | Current Thread | [Next in Thread] |