I'm involved a lot in Gnu Radio and the USRP hardware from Ettus, rather
than the Roach boards from CASPER. But I have some questions
about host-side processing, that the folks on this list might have
some insights into.
The USRP hardware was just upgraded to allow the use of 8-bit samples,
Hi Marcus,
I wonder if anyone on this list has done more-than-trivial processing,
in real time, on sample streams approaching 50Msps in a host
computer environment, as opposed to the usual FPGA environment.
If so, what kind of CPU? How much memory? What kind of network interfaces?
Adam
hi marcus,
there are several casper instruments that digitize data using
ADC's plugged into one or more FGPA board(s).
The FPGA boards packetize and time stamp the ADC data
and send it over 10Gbit ethernet
to one or more CPU's and GPU's.
here are a couple of examples.
the VEGAS instrument
On Sun, Nov 20, 2011 at 9:26 AM, Marcus D. Leech mle...@ripnet.com wrote:
My current interest is CPU-only. Most of the papers I've read about
GPU-based implementations aren't terribly encouraging for
implementations where only part of the job is performed on the GPU. The
overhead costs are
Hi Marcus,
I felt compelled to chime in. We have no direct experience with Casper
hardware - but have deep experience in both opencpi.org and netfpga.org .
In both cases we are in the business of allowing heterogeneous compute
resources (e.g. GPP, GPU, FPGA) to interoperate. At the risk of
On 11/20/2011 12:57 PM, Yashwant Gupta wrote:
Hello Marcus,
At the GMRT, we have a fully real-time all CPU based correlator +
beamformer + pulsar receiver that takes in data from 64 analog inputs
(32 antennas, dual polarization) each at 66 Msps max.
I refer you to a publication that
On 11/20/2011 03:47 PM, John Ford wrote:
Have you done any profiling to see where the cycles are going? It seems
on the surface that your 6 core Phenom system should be capable of
processing 50 Megabytes per second.
John
It's not the data rate that's the issue, I can happily consume 50Msps
Hey Marcus,
One thing that has helped us a fair bit is keeping a close eye on
interrupts. In particular making sure that you set appropriate IRQ
affinities (via /proc/irq/irq#/smp_affinity), so that one core is not
doing all the
lifting when it comes to I/O and other tasks. In our case keeping
8 matches
Mail list logo
