Hi all guys again,
After few posts and numerous tries to set up MM sync block, I finally want
to give up, and before I start with some kind of ad-hoc approach I want to
ask for help to setup polyphase Clock Synchronizator.
This block is very well documented (by the way, it looks like description
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
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
Hi Dominique,
My question is how to use this API in C++ or python with the UHD
gnuradio blocks.
if you haven't already, I'd recommend reading (and trying out)
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
What you'll want to do is most probably:
Write your flowgraph in
I pulled and made the latest trunk and i get the following test error:
The following tests FAILED:
217 - qa_ofdm_txrx (Failed)
Errors while running CTest
make: *** [test] Error 8
this is on a Fedora 17 64-bit
Achilleas
___
Discuss-gnuradio
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
On Fri, May 17, 2013 at 11:29:27AM -0400, Achilleas Anastasopoulos wrote:
I pulled and made the latest trunk and i get the following test error:
The following tests FAILED:
217 - qa_ofdm_txrx (Failed)
Errors while running CTest
make: *** [test] Error 8
this is on a Fedora 17 64-bit
On Fri, May 17, 2013 at 11:29:27AM -0400, Achilleas Anastasopoulos wrote:
I pulled and made the latest trunk and i get the following test error:
The following tests FAILED:
217 - qa_ofdm_txrx (Failed)
Errors while running CTest
make: *** [test] Error 8
this is on a Fedora 17 64-bit
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
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: master.of.knowle...@gmail.com
OK please scratch that out.
I had a minor problem with scipy.
Once it was reinstalled everything was fine.
Achilleas
On Fri, May 17, 2013 at 11:29 AM, Achilleas Anastasopoulos
anas...@umich.edu wrote:
I pulled and made the latest trunk and i get the following test error:
The following tests
On Tue, May 14, 2013 at 10:03 AM, Tom Rondeau t...@trondeau.com wrote:
On Mon, May 13, 2013 at 8:00 PM, Michael Buettner
michael.buett...@gmail.com wrote:
I am trying to use an out of tree module (built according to the
Out-of-tree modules documentation) from a C++ application. The
module is
I think you are missing the point. In order to support massive parallelism,
data must be duplicated as it comes of the wire and into memory. Not
duplicated in FIFO streams in an application. The latter is a software
implementation of a hardware task and is consuming resources.
It requires
I think you are missing the point. In order to support massive
parallelism, data must be duplicated as it comes of the wire and into
memory. Not duplicated in FIFO streams in an application. The latter
is a software implementation of a hardware task and is consuming
resources.
It requires
On Fri, May 17, 2013 at 9:55 AM, Mark McCarron mark.mccar...@live.co.ukwrote:
In order to support massive parallelism, data must be duplicated as it
comes of the wire and into memory. Not duplicated in FIFO streams in an
application.
There is no duplication of buffer contents in GNU Radio.
Guys,
This places a limit on the performance of GNURadio that can be avoid through a
push for a more modern type of DMA.
The ideal scenario is to never copy data and it is achievable, to a degree,
through proper planning. If you look at your argument, you are essentially
saying that it is
The ideal scenario is to never copy data and it is achievable, to a
degree, through proper planning.
I have to strongly disagree with that.
You have to realize what a /driver/ is. And why it is needed:
A driver takes whatever ressources a piece of hardware offers and makes
these ressources usable
Marcus,
I was writing the Windows driver for Per Vices Corporation (Phi/Noctar) last
year, I know how drivers work. I should have mentioned that earlier.
What you are missing is the fact that the DMA must occur first before anything
can get to a cache. So, if we are writing to memory in
This was actually supposed to go to the list as well.
-- Forwarded message --
From: Hilbert Transform hilbert3...@gmail.com
Date: Fri, May 17, 2013 at 2:48 PM
Subject: Re: [Discuss-gnuradio] Question about UHD driver
To: Mark McCarron mark.mccar...@live.co.uk
Mark:
First, it's
I don't know if I agree with this. I don't usually have issues with the memory
bus. Every problem I have encountered, in terms of bottlenecks, is nearly
always related to I/O. The CPU is useless at this and that's why we have DMA.
With constant streams of real-time data, there is a fixed
Hi Mark,
I wasn't assuming you didn't know what a driver is - I was just hoping
you'd try to realize more clearly,
that especially for something like network packets, you need a hardware
driver (and the network stack of the os)
to make use of your dma'ed data.
You're totally right that data from
Hey,
i changed tx_ofdm and rx_ofdm to communicate through a fifo (named
pipe) instead of USRPs
and i seem to have problems making them work.
It seems that when rx_ofdm starts one of the threads goes to 100%
but nothing comes out of the debug_tag block at the end of the
receiver, which indicates
So, you think the penalty of processing in the stack, outweighs the performance
gained by having duplicate streams?
You do realise they are being processed in parallel in the stack???
By the time you would start the copy, my modified DMA would be ready under all
scenarios.
Regards,
Mark
23 matches
Mail list logo
